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

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
>    <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
>    <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/