Hi all,

Thanks for pointing out software statements. The goal of Protected Dynamic Client Registration is to link the software statement and the user claims created at the RqP's AS with the registration process at the RO's AS. The software statement should be created and then inserted into the claims token at the RqP's AS, then sent by the client to the RO's AS, then after the authorization assessment, an RPT is created which acts as the initial registration access token that contains this software statement. Thus, the registration process can be done in a controlled manner. I'll try to clarify this in the draft.

My original idea was that the client would do a DCR for each RqP. To be honest, I'm not sure at this point if it makes sense.

Regards

-Igor

On Thu, Oct 14, 2021 at 4:32 PM Alec Laws <malcolm.laws@gmail.com> wrote:
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-14

Minutes

Roll call

  • Quorum: No

Approve minutes

Deferred


Document Development

GDocs/etc. is problematic so let's find an alternative and use it for everything

  • Maybe Kantara's github? good for publishing/versioning, maybe not best for commenting
  • Use markdown?
  • Confluence? Good for commenting/iteration, can always move to github to publish if necessary

Let's use confluence for document development. 

If you need an account, it's easy to self-register (look at the top right of this page). Reach out to Alec if you have issues


Protected Dynamic Client Registration

https://github.com/uma-email/poc#protected-dynamic-client-registration


If we want wide-ecosystems, then DCR is necessary and doesn't seem to need more gates. The spec already includes software statements. What is the gap in the existing spec that needs to be addressed?

The current proposed DCR links a client to a RqP. Is the intention that the client always does DCR for each RqP, or the first RqP facilitates the clients CDR?


Delegation and Guardianship

Goal, collect a few delegation/guardianship/association use cases and show how to implement in UMA. glossary or report to analyze these cases in UMA terms? Update to UMA Legal deck → report?


There is a set of UMA business use-cases already, including delegation of decision making (substitute decision maker) and the process of establishing that delegation. 

There is a new set of use-cases for another group (pp2pi) that are deliberately hard to achieve. Want to review these cases and see if existing UMA cases cover them, or if we can build new UMA guidance to address them. 


On the 25th we can review the existing Use Case work, and compare with the links above


If you have delegation use-cases, please bring them forward on the mailing list


AOB


Anyone going to the FIDO Authenticate conference next week? 

There are also OIDF meeting next Thursday 


Recent news on FHIR vulns:

https://www.scmagazine.com/analysis/application-security/critical-flaws-found-in-interoperability-backbone-fhir-apis-vulnerable-to-abuse

https://www.healthcareitnews.com/news/cybersecurity-briefs-olympus-it-outage-fhir-vulnerabilities-and-more


IIW quick impressions:

  • hugely focused on SSI/TOIP/DID/VC, very few OAuth/web authorization based sessions
  • people are trying to apply these new technologies to all transactions, need to bring existing OAuth/UMA concept back into the discussion
  • separating security from the transport protocol is a very interesting idea. often the protocol security is linked to transport security (eg oauth + tls)
  • challenges today are around interoperability, still trying to bring it together, ex so any did method can be used in any VC scheme
  • ideally we can bring some UMA content to the next IIW, show the intersection between DID/VC and existing web authorization systems


Check out the mozilla objections to the DID spec:https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html

And a response from Evernym: https://www.evernym.com/blog/w3c-vision-of-decentralization/


Topic Candidates (from previous week's telcon)

  • Delegation and Guardianship

  • Outcome of user stories discussion

  • PDP architecture includes the concept of governance registry/discovery

  • TOIP/SSI are starting to define this ecosystem function

  • ANCR records update

  • Privacy as Expected/ANCR update : 2/3 weeks out (Sal?)


Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)

Voting:

  1. Eve
  2. Alec
  3. Steve
  4. Sal
  5. Thomas

Non-voting participants:

  1. Scott
  2. Zhen
  3. George
  4. Nancy
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma