August 2020 - WG-UMA - mailman.kantarainitiative.org

Policy Manager
by Alec L 02 Sep '20

02 Sep '20

Hi, To our discussions, I’ve started to break out just the RO policy manager component of the original wallet spec Best, - Alec Alec Laws 647 822 1529 alec(a)identos.ca — ## 1. Introduction This document extends [UMA Fedz] in order to specify the interface provided by the AS to the RO for policy management. This is achieved by introducing a Policy Management API specification and client type which represents the RO: the UMA Policy Manager. This new client type is authorized to use the policy API after being authorized by the RO as the AS. THis is the same mechanism used by an RS to put resources under protection, the RS is issued a PAT by the AS. This new client provides a few key benefits to an UMA ecosystems - The AS may delegate policy management user expereince and advicce to another party - The RO is able to choose this client, where they may not be able to choose an AS or RS. The RO receives a consistent policy management interface - The RO may manage resources at many AS's to have a complete view of their resources and policy For example, there are two UMA AS's, one being operated by the Alice's local health authority and one operated by Alice's personal Bank. Alice's resource servers are only able to accept authorization decisions from those RS, effectively Alice must use those RSs to protect her resources. When those AS's support this profile, they give back some agency to Alice in how she manages her resources and policy, and reduce their own need to provide this UX (maybe each AS provides on UMA Policy Manager by defaults, but also accept third party policy management services). Alice may then manage policy across all of her RS's and AS's from a single control panel. ### 1.1 Notational Conventions ### 1.2 Abstract Flow ``` +------------------+ | resource | | owner | +------------------+ | | v +------------------+ | Policy | | Manager | +------+-----------+ | | manage (a PAT type authz?) | | v +-----------+ | policy | | API | +-----------+ +---------------+--+ | | | authorization | | server | | | +------------------+ ``` This specification uses all of the terms and concepts in [UMAGrant] and [UMA Fedz]. This figure introduces the following new concepts: - UMA Policy Manager - Policy API The API presented by the AS to the Policy Manager. This API is OAuth protected ### 1.3 HTTP Usage, API Security, and Identity Context ## 2 Authorization Server Metadata TBD ## 3 Policy API note: this API is very similar to the permission endpoint, expect the payload includes an RS sub, additional policy condition, and is signed by a RO-RS credential The API available at the policy_endpoint enables the policy manager the modify policy over the RO's protected resources. These policies define the claims gathering requirements for an RqP to gain access to the resource, and should also indicate the intended purpose/use for resource access. Management of the policy beings on successful creation and ends on successful revocation. The relationship manager uses a RESTful API at the authorization server's policy endpoint to create, read, update, and delete policy descriptions, along with retrieving lists of such descriptions. note: I think it's also useful to allow the RO to read a list of registered resources, I don't think would live under the policy_endpoint, it's essentially like the GET API from the resource_registration_endpoint with additional information about the RS? note: through the ` "user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy"` the RS could also let the relationship manager know (though manage API) what path to use at the AS to modify policy for this resource?? This restricts Figure TDB illustrates the policy API operations, with requests and success responses shown. ``` FIGURE TDB ``` - user authz to use the API, same as RS getting a PAT -> continuity of resources, "account at the AS" - read rs's - read registered resources - organized by RS? - manage policy - resource(s) + acceptable claims conditions ### 4.a Policy Description A policy is a JSON document, that describes the a policy sufficiently for the authorization server to make a decision for a resource request. A policy document MAY be provided as a signed JWT to ensure it's integrity to the RS during enforcement. A policy description has the following parameters resource_id REQUIRED The resource id registered at the AS that this policy applies to resource_scopes REQUIRED The approved scopes if the claims requirements are met claims REQUIRED An array of claims/attributes that must be presented by the RqP in order to access this resource under this policy optional/extension/discussion: sub The subject known by the RS for this RO (useful for general resource definitions) resource_server (again, useful for general resource definitions) client_id The client application that may be used to access this resource intent The purpose/intention of resource use the RqP must accept For example... ``` { resoruce_id: "KX3A-39WE", "resource_scopes": [ "read-public", "post-updates", ], claims: [ ??? ] } ```

4 3

Draft minutes of UMA telecon 2020-08-27
by Eve Maler 27 Aug '20

27 Aug '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-27 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> , 2020-07-23, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23> 2020-07-30, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30> 2020-08-06, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06> 2020-08-13, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-13> 2020-08-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-20> Deferred. Sustainable Self-Sovereign Agents (S3A) There was a meeting held earlier today – notes and a recording here <https://docs.google.com/document/d/1kZ7_Skcn4zb3zOfEu7XZDrYAmLR1T_pbBoSk8AE…>. For more info or to get involved, contact Adrian. UMA is being put in play. PKCE and UMA wrapup Any final *quick* comment on this? Alec has suggested some updates to his latest wording in this email thread <https://groups.google.com/g/kantara-initiative-uma-wg/c/t72iQgd2qEU>, though he's not perfectly happy with it. Eve suggests putting it in the UIG anyway, and drawing people's attention to the (non-normative) wording for use and comment. Adrian notes that a UserInfo endpoint, interacted with in a fashion that is sort of variable in the SSI context (e.g. the first contact could be a QR code), could be an interactive claims gathering endpoint. We have also in the past discussed how we need notification functionality, which requires out-of-band endpoints. Relationship Manager profile Alec sent thoughts on the policy manager API in this email thread <https://groups.google.com/g/kantara-initiative-uma-wg/c/1BcBSR_FnJA>. Let's see if we can capture a deeper "why"/comparison statement that could go into the profile. (See the openings of the UMA2 specs for an example.) Alec's new wording does contain this sort of why/comparison/motivation. In other words, in the case where the AS is a "multi-user" AS and Alice (the RO) has no choice about which one it is that she has to use, we want to make sure to preserve as much of Alice's agency (control) in the situation as possible. So pushing policy management out of the AS and into a client app gives Alice this point of control. She wants some freedom to independently verify who is providing advice about what policies to choose. We have, in the past, discussed AI engines that implement things like relationship-based policy. This client could provide such functionality. The token that protects this policy management interface is different from the PAT but is similar to it. Let's call it a "PMT" right now, for argument's sake. The FPX work that is being dropped here is the policy manager's interaction with the RS. The previous discussions we were having about "cascading" AS's had to do with the situation when the server-side (multi-user) AS might hold some policy and the client-side (Alice-specific) relationship manager/policy manager might hold some policy too, and then you have to figure out policy ordering. But Alec has left that out for the sake of simplicity. Adrian objects to working on this profile because it optimizes for a situation where the server-side AS isn't Alice's fiduciary. Alec believes there is nothing in the profile that precludes the RS from presenting 10 AS's and letting the RO choose. Eve believes that Tim has previously concluded that any server-side AS that serves multiple users would have a hard time being anything more than a limited fiduciary (but we have to check). As well, a key requirement expressed by a number of healthcare players has been to "federate" policy management across multiple servers, so this seems to be consistent in a certain sense. Her past discussions with Nancy revolved around "consent management servers" (CMS's) and she brainstormed a "consent access token" (CAT?) to protect a "consent API". Domenico notes that PSD2 has the concept of a collector – an aggregator of data from multiple bank institutions. This is what this "RO client" (can we call it that? Thomas suggests it) enables the RO to do with policies, across any number of AS's, whether the RO chose them or not. Scott has been context-switching every time he hears "client", thinking it means our classic "UMA client" that the RqP uses, so we should also qualify "client" when we mean the one that the RO uses. Should we go back to the RO-client interfacing with both AS's and RS's? Let's think about that. Adrian loves the notion that the market wants some kind of policy management wallet or agent. [image: (smile)] Is this bidirectional? Is it a read/write API? He suggests extending the "Adrian clause" to the AS as well the RS. Let us ponder that. Eve adds on top: We may want to think about another modular profile that we should consider drafting, a "prove to Bob that Alice is who she says she is" profile, now that we'll have an RO-client that incidentally allows for Alice-authentication. This would help us solve for CIBA-like use cases (which we've discussed ad nauseam before). *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 4

PKCE + Interactive Claims Gathering
by Alec L 27 Aug '20

27 Aug '20

Hi, We’ve had some requests to add PKCE [1] to the interactive claims gathering flow [2], eg example for public clients. Technically, there is little challenge to directly apply the PKCE code challenge/verifier, with the assumption that the authorization code is equivalent to the uma ticket Has anyone done this? Any additional considerations? Thanks, - Alec Alec Laws 647 822 1529 alec(a)identos.ca [1] PKCE: https://tools.ietf.org/html/rfc7636 <https://tools.ietf.org/html/rfc7636> [2] https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#clai… <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#clai…>

2 4

MyData Program Planning Zoom - Thursday 8/27 10AM EST
by Adrian Gropper 27 Aug '20

27 Aug '20

MyData is offering the SSI communities a significant platform to promote our standards and broaden our outreach at and around their annual meeting in December. I'm organizing a program proposal on DID and UMA-centered interoperability and hoping for broad participation. The details, including a novel idea, are in this document: https://docs.google.com/document/d/1kZ7_Skcn4zb3zOfEu7XZDrYAmLR1T_pbBoSk8AE… Please join a program planning Zoom 8/27 10 AM EST. - Adrian

2 1

Agenda for UMA telecon 2020-08-27
by Eve Maler 26 Aug '20

26 Aug '20

1 0

Draft minutes of UMA telecon 2020-08-20
by Eve Maler 20 Aug '20

20 Aug '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-20 MinutesRoll call Quorum was not reached. Approve minutes - Approve minutes of UMA telecon 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> , 2020-07-23, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23> 2020-07-30, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30> 2020-08-06, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06> 2020-08-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-13> Deferred. PKCE and UMA; why to identify clients; who has a stake in identifying clients Discussion with George: As long as the permission ticket is refreshed on every claims gathering round (which it is), and only the most recent permission ticket is accepted in the next round (which it should be), we should be okay. PKCE is trying to prevent "waking up someone else's app". Android doesn't have quite the same discipline as Apple around scheme/app checking. Our analogy is permission ticket .eq. authorization code. If the code challenge is sent in an ICG flow, does it have to be sent to the token endpoint? We might need to provide some direction around what to do if the client generates the new value, or possibly say it shouldn't. Is getting the same hash multiple times better than multiple hashes in multiple rounds? Interception of the response would be the problem. We could write a profile of DPOP. The client could pass in its key, which would get bound to the permission ticket. That would prevent any intercepted message from an alternative client from being interpreted as legitimate. We could also be more prescriptive around DCR. DPOP was meant to help in the situation around SPAs. For mobile apps, you register it with the AS, and then you can use whatever POP method you want. OAuth 2.1 helps a bit (as previously noted) because PKCE is mandated; this brings client identification. DCR brings a persistent client identification and authentication mechanism. AI: Alec: Continue to massage the UIG blurb to include these new insights. In a bring-your-own-device context (which we now frequently see in healthcare and other sectors), we're finding it important to dynamically register (identify and subsequently authenticate) UMA client applications used with those devices. Adrian notes that there is some trouble out there handling software statements for clients. And he's aware of US law that says that a client application unrecognized by an AS can't be refused, and its user, the patient, can only be issued a "black box warning" (there is no distinction in the law between blocking the client and blocking the patient). George believes UMA fits in this model quite a bit better than OAuth because it doesn't require "trust" in the client. Then a process begins to look at proof around the RqP entity against the policies protecting the resource. There is little awareness among people not at this table that RS's are able to outsource client management to the AS simply because the client can remain relatively untrusted; as long as the client is simply persistently identifiable throughout a single run of the protocol (it's "the same dog" throughout), it shouldn't much matter what it actually is, because claims would be gathered about the RqP to satisfy policy in granting resource access. Even though this feature is native to UMA, the resource definition profile seems to enhance the comfort level of RS's in making the AS a kind of community trust anchor for clients (not the original purpose of the profile; it just worked out this way). Could we complete a deeper analysis of the native feature and then publicize it better? Leveraging RAR for the client presenting claims could be interesting, and PAR could be used as a security technique as well. Adrian mentioned the work of IEEE's "P2933 - Clinical IoT Data and Device Interoperability with TIPPSS (EMB/Stds Com/Clinical IoT DDI... Home". George mentioned: "Google's WebID proposal is in the W3C Incubator Community Group (WICG) and Apple's isLoggedIn() proposal is being discussed in the W3C Privacy Community Group (WPCG)" If people can get involved in these communities, that's helpful. Not directly related to UMA, but browser support for identity stuff is relevant. Lots of stuff we could profile here, in order to take advantage of new OAuth-related tools to strengthen UMA's abilities. Relationship Manager profile Alec's latest spec text is in this thread <https://groups.google.com/g/kantara-initiative-uma-wg/c/vcB9S3mksn8>. Deferred this time. Attendees As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Michael 2. Sal 3. Thomas 4. Eve Non-voting participants: - George - Scott - Adrian - Anik - Alec - Colin *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

We have our call tomorrow on the primary-week schedule
by Eve Maler 19 Aug '20

19 Aug '20

The call is at 6:30am PT. We are still working on the Relationship Manager profile. Details are on the calendar: https://kantarainitiative.org/confluence/display/uma/Calendar Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Draft minutes of UMA telecon 2020-08-13
by Eve Maler 13 Aug '20

13 Aug '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-13 MinutesRoll call Quorum was not reached. Approve minutes - Approve minutes of UMA telecon 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> , 2020-07-23, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23> 2020-07-30, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30> 2020-08-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06> Deferred. PKCE and UMA Do we, in fact, have to say anything about repeated ICG cycles. You get a refreshed ticket from the redirect cycle, and don't have to "pass go" (go through the token endpoint) when you do that. If a token call is made, then we're good because there's a natural mitigation. If not, then we probably need to do more analysis. Calling George Fletcher <https://kantarainitiative.org/confluence/display/~openid@gffletch.openid.ao…> – any opinion? Relationship Manager profile Alec's latest spec text is in this thread <https://groups.google.com/g/kantara-initiative-uma-wg/c/vcB9S3mksn8>. A Relationship Manager (RM) should be able to interact with multiple AS's. Policy setting interactions with an app and RqP-type interactions at an app should be able to be totally separated. In the UMA1 world, we had a notion of OAuth-protected APIs that were standardized by UMA, called the "Protection API" and the "authorization API" (only the former survived in UMA2). As a result, the "UMA AS" (noting that we have based UMA concepts on OAuth, in a very real and important sense – borrowing token handling and such) had to play the putative role of an "OAuth AS and RS" because it has the job of presenting these OAuth-protected APIs. It's a little bit like turtles all the way down. *Somewhat* similarly, we now have the situation that an individual may want to use an app that allows for policy setting to protect their resources (*control API or protect API* – but watch out for naming because we already have a "*protection API*" in UMA2 FedAuthz that governs the AS-RS interface), *and* an individual may want to use an app that allows for managing their claims (*manage API*), and we now want to standardize these APIs in order for an AS to interact with a client application to do each of these functions interoperably. *If* the *same* app is used by the *same* individual such that they set policy at an AS to protect their claims (for use by that same AS or a different AS in the course of satisfying UMA policy), *then* that individual is an *RqP* (as well as being an RO by definition because we're on the "phase 1" side of UMA) *and* that single app is a Relationship Manager by virtue of the colocation of the two APIs in one app. Thomas notes that in this scenario, the API is a "resources-control" API because it is, in practice, controlling resources, and a "claims-manage" API because it is, in practice, managing claims as the specific resources. Is it sufficient, in that case, to simply say that if the manage API is UMA-protected and control-API standardized, then RO=RqP? It's more like the client (or user agent) is "cascading" in this scenario, because it calls both the manage API and control/protect API. Big question: Is it possible for the two APIs to be specified entirely separately, because they could be called separately? Maybe – or maybe not, since the "wallet" concept and individual control were at the heart of the original proposal. Sal says: I think RO_RQPT is at the crux, and to solve the Notice and Consent "Problem" is that the RO_RQPT needs to be in possession of policy and that consent is agreed not forced down. Thomas adds: The RM is the point at which to set consent rules. Attendees As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Michael 2. Peter 3. Sal 4. Thomas 5. Eve Non-voting participants: - Scott - Alec - Adrian - Patrick - Bjorn *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Relationship Manager - draft spec text (aka UMA Wallet)
by Alec L 13 Aug '20

13 Aug '20

Please find some updated spec text below. Changes are mainly to: intro, policy api, AS metadata, add (empty) introspection section, add spec-is wrapper/formatting Perhaps should be pushed to the UMA GitHub (as Eve has been hinting at!) Cheers, - Alec Alec Laws 647 822 1529 alec(a)identos.ca # UMA Relationship Manager (aka Wallet) | | | |:---|:---| |Version:|0.1| |Document Date:|2020-07-30| |Editors:|Alec Laws| |Contributors:|| |Produced by:| |Status| | |Abstract| | |Suggested Citation| | #### Notice IPR Option: Non-Assertion Covenant Copyright: The content of this document is copyright of Kantara Initiative, Inc.© 2020 Kantara Initiative, Inc. ## 1. Introduction This document extends [UMA Fedz] in order to specify the management and control interfaces through an UMA Relationship Manager Client. This new client type defines how an Resource Owner may connect to Resource Servers, put those resources under protection and finally create and manage policy at an AS over those registered resources. This role is a Client application that may be accessible to the end-user through various user-agents (eg Browser, native app) This new client type provides the end-user a consistent consent management interface that may be used across multiple ASs, where the RO is able to choose an independent policy management service, or tightly coupled to a single AS. In some profiles, this extensions enables the AS to operate with a minimum of collected personal data. The UMA Wallet operates in two distinct modes, for the RO and the RqP. The UMA Wallet performs three major flows with other systems: 1. RO puts resources under protection 2. RO creates policy 3. RqP performs claims gathering, ### 1.1 Notational Conventions ### 1.2 Abstract Flow ``` +------------------+ +------------------+ | resource | | requesting | +---------- | owner | | party | | +------------------+ +------------ -----+ | | delegation | | +------------------+ | | | | +-----manage ---------- Wallet | | | +------+-----------+ | | | +-----------+ | | | | claims | | | | | gathering | | | | | API(OIDC)| | | protect +-----------+ | | | ^ | | | | | | | | | v v | | +-----------+ protection +-----------+ | | | manange | API access | policy | | | | API | token (PAT) | API | | + +-----------+ +-----------+ | +------------+ +----------+---------------+--+ | | |protection| | | resource | | API | authorization | | server |<-----prot---| (needs | server | | | | PAT) | | +------------+ +----------+------------------+ ``` This specification uses all of the terms and concepts in [UMAGrant] and [UMA Fedz]. This figure introduces the following new concepts: - UMA Wallet - Policy API The API presented by the AS to the Wallet. This API is OAuth(UMA?) protected - Manage API The API presented by the RS to the Wallet. This API is OAuth(OIDC?) protected ### 1.3 HTTP Usage, API Security, and Identity Context ## 2 Authorization Server Metadata This specification makes use of the authorization server discovery document structure and endpoint defined in [UMAGrant]. The relationship manager uses this discovery document to discover the endpoints it needs. In addition to the metadata defined in that specification and [UMA Fedz], this specification defines the following metadata for inclusion in the discovery document: policy_endpoint REQUIRED The endpoint URI at which the relationship manager modifies policy on the user's behalf The Authorization Server should indicates it's support of this profile by including the URI to the specification in the uma_profiles_supported metadata array ## 3 Manage Endpoint The management API allows the wallet to manage resources on behalf of the authenticated resource owner. The manage API allows the RO to register credentials (public keys... or otherwise) the RS will trust policy signed by. The policy is delivered by the AS to to RS in the RPT or through introspection. The manage API may be extended to allows the wallet - to read available resources, - direct the RS to register resources at a specific AS, and see ASs/registered resources - dynamic registration of an RO specific client ### 3.1 Create Credential Example ``` POST /credential Authorization: Bearer something { oauth dyn client reg with a embedded jwk } { a DIDDocument... } ``` ## 4 Policy API note: this API is very similar to the permission endpoint, expect the payload includes an RS sub, additional policy condition, and is signed by a RO-RS credential The API available at the policy_endpoint enables the relationship manager the modify policy over the RO's protected resources. These policies define the claims gathering requirements for an RqP to gain access to the resource, and should also indicate the intended purpose/use for resource access. Management of the policy beings on successful creation and ends on successful revocation. The relationship manager uses a RESTful API at the authorization server's policy endpoint tto create, read, update, and delete policy descriptions, along with retrieving lists of such descriptions. note: I think it's also useful to allow the RO to read a list of registered resources, I don't think woudl live under the policy_endpoint, it's essentially like the GET API from the resource_registration_endpoint with additional infomration about the RS? note: through the ` "user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy"` the RS could also let the relationship manager know (though manage API) what path to use at the AS to modify policy for this resource?? This restricts Figure TDB illustrates the policy API operations, with requests and success responses shown. ``` FIGURE TDB ``` ### 4.1 Policy Description A policy is a JSON document, that describes the a policy sufficiently for the authorization server to make a decision for a resource request. A policy document MAY be provided as a signed JWT to ensure it's integrity to the RS during enforcement. A policy description has the following parameters resource_id REQUIRED The resource id registered at the AS that this policy applies to resource_scopes REQUIRED The approved scopes if the claims requirements are met claims REQUIRED An array of claims/attributes that must be presented by the RqP in order to access this resource under this policy optional/extension/discussion: sub The subject known by the RS for this RO (useful for general resource definitions) resource_server (again, useful for general resource definitions) client_id The client application that may be used to access this resource intent The purpose/intention of resource use the RqP must accept For example... ``` { resoruce_id: "KX3A-39WE", "resource_scopes": [ "read-public", "post-updates", ], claims: [ ??? ] } ``` --- updated to this point ### 4.1 Policy Description The policy is a JWT signed by a RO credential known to the RS that owns the resource_id Example Payload ``` { "sub": "a RO chosen sub to identify to the RS" "resource_scopes":[ "view", ], "resource_id": "resource_id", ...extension/optional "client_id": "resource_server": "req'd for res def profile" "other_conditions" "" } ``` ## 5 Claims Gathering (OIDC) THe claims gathering API allows the AS to delegate RqP authenticate and claim collection to the Wallet. The wallet allows the RqP to respond to a registered RO policy for the requested resource. ## 5 Introspection In some cases, policy should be conveyed through the AS back the RS for independent verification ## Security Considerations ## Privacy Considerations ## Acknowledgments ## References --- ## Authors' Addresses

1 1

Agenda for UMA telecon 2020-08-13
by Eve Maler 13 Aug '20

13 Aug '20

We are on our “alternate-week” schedule, meeting at 10am PT. Calendar with details is here: https://kantarainitiative.org/confluence/display/uma/Calendar We’re still working on the Relationship Manager profile. Let’s try to push ahead on spec text if we can. Let’s also do a quick roundup of healthcare/ONC goings-on and how we can contribute. (Sorry for the informal agenda. I’ll have a proper meeting/minutes doc for us eventually!) Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0