Sincere apologies for cross-posting but I think this goes to the heart of the overlap between the worlds of federated and self-sovereign technology and their mutual interest in delegation. This is also central to the way UMA, OIDC, and the W3C identity and claims standards work together to drive personal agency in our HIE of One implementation. Here's the data model for the W3C verifiable claims / credentials https://w3c.github.io/vc-data-model/#ecosystem-overview

In HIE of One, the AS accepts either federated (OIDC) or self-sovereign identity of the RqP and needs to interpret their claims either way. We do this because we need to apply the delegation power of UMA to ultra-diverse systems, like healthcare, where federation has not worked to-date.

I'm not sure where we might go from here, hence the cross-posting. HIE of One currently implements OIDC and one of the Decentralized ID-standards-track methods. We hack the social-login of a restricted network https://docs.janrain.com/social/identity-providers/#doximity-social-login-configuration-guide to add a verified medical credential to the doctor's DID wallet. Earlier this week, I had interest from one state agency credentialing first-responders. A decentralized system would be more robust in a disaster response scenario.

HIE of One tries to achieve the best of both worlds and leave the choice of exposing and accepting claims to the individual humans involved.

I think we can do more by recognizing and harmonizing our standards.

Adrian



On Thu, Aug 9, 2018 at 1:41 PM, Eve Maler <eve@xmlgrrl.com> wrote:
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-09

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2018-06-14, 2018-07-12: APPROVED by acclamation.

Financial and health multi-portal use cases and solutions

Deferred.

News from the wider UMA world

We have been hearing that WSO2 has been planning an UMA2 implementation this quarter; Eve will check in with Prabath.

Eve has updated the Implementations page's Keycloak entry to supply Pedro's provided information. It appears that there is an extension to the permission endpoint to all the RS to push claims to that endpoint. "When creating tickets you can also push arbitrary claims and associate these claims with the ticket ... (example shown) ... Where these claims will be available to your policies when evaluating permissions for the resource and scope(s) associated with the permission ticket.". Is is something that would be interesting to standardize for interop? We can ask Pedro in email. He had proposed an extension (see issue 355) that would shortcut using a permission ticket at all, for narrow-ecosystem enterprise purposes.

Mike is meeting with Pedro tomorrow to discuss interop testing. Mike's demo at Identiverse can be turned toward such purposes, with Keycloak as the AS. It looks like both Keycloak and ForgeRock implement just claims pushing for their claims collection flows at this point. Gluu's OXD server has a kind of UMA client middleware capability, and it would be happy with either type of claims collection. The typical assumption in pushed-claims flows these days is that Alice's AS is her IdP and also Bob's IdP, but ID token validation should properly still be "full validation", with no shortcuts.

In this kind of ecosystem, obviously the AS can include itself as an additional audience alongside the client as the first audience because it knows ahead of time that it will be the one ultimately consuming it. In any "wider ecosystems" than this, that is, IdPs for Bob that aren't Alice's AS, tokens that get pushed by back-channel means can't be very dynamic about their audience predictions.

An insight about UMA's grant structure and main options, based on the fact that a permission ticket provides a framework for allowing a variety of looping patterns of state-preserving client-to-AS-token-endpoint interaction:

  1. Like the OAuth authorization code grant – useful for fairly wide ecosystems when unexpected RqPs tend to show up
    1. C immediately redirects RqP to AS claims interaction endpoint
    2. AS and RqP do interactive claims gathering
    3. C asks for RPT at token endpoint
  2. Like the SAML or JWT assertion grant profile (not just client authentication) – useful for ecosystems where AS serves as same IdP to both RO and RqP – also like ordinary SAML or OIDC SSO with login-time attribute exchange, where Bob is trying to get into some enterprise protected resource, only the resource is Alice's to protect
    1. C pushes claim token (say, ID token) to token endpoint on behalf of RqP and asks for RPT
  3. A hybrid flow, or if the AS didn't statically declare its claims interaction endpoint in its metadata
    1. C asks for RPT at token endpoint (with or without pushing claim token)
    2. AS sends need_info error with redirect_user hint
    3. C redirects RqP to AS
    4. AS and RqP do interactive claims gathering
    5. AS redirects RqP back to C 
    6. C asks for RPT at token endpoint 

In Eve's discussion with Bertrand Carlier for his (forthcoming?) blog post, he had the insight about the authorization code flow, pointing out the analogy of the permission ticket to a "mutable authorization code" (along with noting that the PCT is very like a refresh token and the RPT is like – is! – an access token). It has been asked why we have a claims interaction endpoint, and didn't reuse the actual authorization endpoint. Mike does refer to the claims interaction endpoint as our "authorization endpoint", which is helpful rhetorically. Although it might take forensic analysis of our archives (smile), we might never have formally considered reusing the authorization endpoint directly vs. the claims interaction endpoint (former name in UMA1: requesting party claims endpoint). Our main design effort for UMA2 was inspired by the exploration in MPD (see here, for example). However, note that customization would have been required anyway, and the semantics of the UMA version cover gathering of claims beyond just verification of a unique identity.

Identiverse talks that touched on UMA:

News from the wider OAuth and OIDC worlds

One tidbit: Eve remotely attended the first OAuth WG session during the Montreal IETF 102 meeting. During this session, Justin mentioned UMA, CIBA, and the Device flow as exemplars of applying a permission ticket paradigm that could help the group develop an actual model of what a grant flow is.

We should think about how we can ensure that UMA and the use cases it solves can influence the conversations going on in the OAuth and OIDC communities, and be influenced as appropriate. For example, the distributed OAuth work has parts that bear some similarity to UMA's AS discovery mechanism. It appears the CIBA spec is going to be broken up into a core and a sector-specific spec. Mike took notes on his action item to create an "UMA for decoupled/UMA-protected backchannel endpoint" swimlane. George in chat: Completely agree with engaging with IETF on the new suggestions and overlaps with UMA.

Wikipedia entry(ies) in dire need of updating

Deferred.

Attendees

As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)

  1. Domenico
  2. Maciej
  3. Eve
  4. Cigdem

Non-voting participants:

  • George
  • Tim
  • Scott
  • Colin

Regrets:

  • Andi
  • Thomas
  • Nancy
  • Adrian

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma




--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.