Re: [WG-UMA] Draft minutes of UMA telecon 2018-08-07

Eve,

This is Michael responding to your question.

Yes, you should update the HIE of One entry as it is now UMA 2.0 compliant.

Our implementation does not use the claims interaction endpoint for claims
gathering.  Because we are using DID through uPort, the claims presented
via that process - which the user presents during the RQP - and then the AS
determines whether the claims presented are adequate for token generation.
Hope that makes sense.

Michael

On Thu, Aug 9, 2018 at 2:39 PM Eve Maler <eve@xmlgrrl.com> wrote:

> Hey Adrian, no worries. Not sure if my reply-all will go through to all
> the aliases listed, but I'll see what happens.
>
> For starters, please let me know if we should update the HIE of One entry
> <https://kantarainitiative.org/confluence/display/uma/UMA+Implementations#UMAImplementations-HIEofOne>
> on our Implementations page.
>
> Since UMA is "ID-agnostic", it's great to know that this design principle
> seems to be working in practice. Does your implementation use the claims
> interaction endpoint exclusively for claims collection, or does it also
> allow pushing claims to the token endpoint? If anyone is making interesting
> use of the claim_token_format parameter, it would be good to know what the
> uses of it in the wild are.
>
>
>
> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>
>
> On Thu, Aug 9, 2018 at 1:04 PM, Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> 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
>>> MinutesRoll call
>>>
>>> Quorum was reached.
>>> Approve minutes
>>>
>>> Approve minutes of UMA telecon 2018-06-14
>>> <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-14>
>>> , 2018-07-12
>>> <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+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
>>> <https://kantarainitiative.org/confluence/display/uma/UMA+Implementations#UMAImplementations-RedHatKeyCloak> to
>>> supply Pedro's provided information. It appears that there is an extension
>>> to the permission endpoint
>>> <https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_permission_api_papi> 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
>>> <https://github.com/KantaraInitiative/wg-uma/issues/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 <https://tools.ietf.org/html/rfc7522> or JWT
>>>    <https://tools.ietf.org/html/rfc7523> 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 [image: (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
>>> <https://github.com/KantaraInitiative/wg-uma/issues/154>, 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 <https://tools.ietf.org/html/rfc6749#section-3.1>.
>>>
>>> Identiverse talks that touched on UMA:
>>>
>>>    - 2018-06-27 Don’t Pave Privacy Cow Paths: Retool Consent for the
>>>    New Mobility - https://www.youtube.com/watch?v=eP5U2sA6EFk
>>>    - 2018-06-27 - Emerging Identity Standards in Healthcare -
>>>    https://www.youtube.com/watch?v=vOypRbpn004
>>>    - Pick u2018-06-27 - UMA 2.0 Deep Dive: Applying User-Managed Access
>>>    - https://www.youtube.com/watch?v=QvvJsEND30c (caption in lower
>>>    third will be fixed)
>>>
>>> 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.
>> DONATE: https://patientprivacyrights.org/donate-3/
>>
>
>