Resource Definitions/AS-first flows
Hi all, Thanks for letting me share some of the extension thinking we’ve been going through at IDENTOS Hopefully the content below adequately describes the first of our changes (RS-first flows) to continue the conversation. Goes through some of the motivation, conceptually how it works,, and calls out items that are particularly different or have challenges being UMA compliant. As many of you noted, in many ways this is a concept of a directory or trust-framework above specific AS/RS/Clients or the actual RO/RqP (intentionally excluding Alice/Bob) Cheers! - Alec Ps More to come on privacy extension, the community vs personal authorization server and SSI alignment # AS first flows/ RS discovery / Resource Server API Interoperability General idea is that many RSs support a very similar API, eg FHIR/OpenBanking/Gitlab, so a Client _should_ be able to use any of those RS, as directed by the RqP. However, the 'very similar' part makes this difficult in practice. Ex two RSs could be FHIR R4, with a different vocabulary set such that the client can't actually use the APIs interchangeably. We believe this is important as a user should have choice throughout the stack, currently choice exists at the Client and AS. Clients must know of/directly integrate to the RS, capping which RSs can be used with the client integration efforts. Current State: UMA moves OAuth towards 'wide-ecosystems' by enabling AS interoperability. A RS can be protected by many AS, and an AS can protect many RS. From the Client's perspective, it only needs to know the RS it wants to access, and can "discover" the AS. ## How it works: ### Setup/Registration: 1. The AS defines general "resource definitions", This is an API standard reference with well defined scopes. - FHIR (scopes: sens/*, conf/*, patient, observation, ...) - FHIR - Patient - FHIR - Immunization - Userinfo - (scopes: first_name, email, birthdate, ...) 2a. Clients are registered with the AS for specific resource definitions - Client A can request a FHIR - Patient - Client B can request Userinfo (first_name), FHIR - Immunization, FHIR - Patient - Client C can request Userinfo (first_name, last_name) 2b. Clients are registered with "capability tickets" (static UMA permission tickets?) for different resource request sets - This could also be achieved in a more uma standard/dynamic manner where the client uses the Fedz Permission API with the general resource definitions - Client B can have a few tickets - "client-ticket-userinfo" -> Userinfo - "client-ticket-immunization" -> FHIR - Immunization - "client-ticket-patient" -> FHIR - Patient - "client-ticket-all" -> FHIR - Patient AND FHIR - Immunization AND Userinfo definitions 3. Resource Servers are registered with the AS for specific resource definitions and the endpoints where they are located - ex - RS X can provide Userinfo (first_name, last_name) - RS Y can provide FHIR - Immunization, FHIR - Patient - RS Z can provide All resources and scopes - The RS has a RO-independant PAT (RS=RO?) in order to introspect ### Client AS-first flow: 1. A RqP appears at Client A, the client needs access to a FHIR - Patient to provide some service 2. Client AS redirects to the AS claims_gathering with "client-ticket-patient" 3. The RqP authenticates (somehow) and can see RSs they can access: RS Y and RS Z - RO/RqP authentication and Alice-Bob delegation are out of scope, handled internally at the AS 4. The RqP selects the FHIR - Patient from RS Y 5. The AS redirects to the Client with a new permission ticket 6. The Client exchanges the ticket for a RPT, the token comes with a "resource_location=RS Y/Patient" - This could also use the token ‘aud’, however, that requires JWT and that the client inspect the token 7. The Client makes the request to RS Y with the RPT 8. The RS introspects the RPT to determine both resource and scopes it's valid for, and also which user/access it's for - The introspection was made with the general RS PAT. The response must include some other information about the specific Resource to access (in this example the specific Patient record) - This step has overlap with our other 'extension' around separating community from personal AS - Currently, when the RS is put under protection the RS/AS decide on a user subject. The AS returns that subject with the introspection so the RS can make internal determination about what specific data to return - Another alternative, when the RS is put under protection is it may register a user specific version of the general resource. During step 4 the RqP can select that specific resource. 9. The RS returns the resource to the client, or can perform the UMA WWW-Authenticate as usual ## Other Considerations: - The client ticket can(?) have multiple resources, and _could_ end up needing the client to receive multiple RPTs? - If we enforce RS-restricted tokens - difficulty here in the format of the token endpoint… current support a normal token endpoint for RS-first and also a “packed” response that returns the multiple tokens if needed - this likely should be a different grant_type - There is some notional alignment with OAuth resource indicators or PAR, haven't looked too deeply Alec Laws 647 822 1529 alec@identos.ca <mailto:alec@identos.ca>
Hi, Here are a few use-cases for discussion around RS discovery The theme here is instead of all RPs needing to know about specific IDP/RSs, the the RP and RS are decoupled through an Authorization Server, allowing the SP to discover which RS to call after user authorization. This requires all RSs to support a standard API, claims_gathering and JWT tokens ## Use Case: IDP discovery, userinfo as a resource Scenario: There are many similar IDPs which may provide standard profile data to a RP, through /userinfo endpoint There are many RPs that would trust any of those IDPs to provide profile data from a user Using RS Discovery, an Authorization Server can manage the IDPs (as RSs) and _all_ RPs Outcome: Reduce integration to only the AS for IDPs(asRS) and RPs - IDPs/RPs can still participate with many AS - user profile data isn't known to AS Notes: Possible, but not nessecary, that the IDPs are an IDP to the AS. User login to the AS through one of the IDP Similar solutions - yes.com which offers bank/idp discovery as a directory/dynamic-ish client registration to the specific IDP - gov.uk verify Alternate Scenario: Even with a single IDP, that IDP can delegates RP onboarding to one or more AS ## Use Case: FHIR Repo Interop There are several clinics which collect healthcare data and offer a simple portal to their patients. Many of the patients request to share their data with other applications. Instead of each clinic curating and vetting all application, they can delegate this to an Authorization Server There are several [healthcare systems] that all support a [FHIR r4] API ## Use Case: Prevent Multiple Required Logins/Resources An RPs requires a user to login to multiple IDPs to authorize an action (for legal/whatever reasons) OR an RP requires data from multiple RSs in order to provide a service The AS can issue multiple access_tokens to the RP... and the RP can make API calls to both RSs with the appropriate constrained token ## Use Case: Data across FHIR Repos A blend of the previous two use cases There are many FHIR systems in a region. Each system maintains a specific subset of a patient record. For example there is an immunization repository and lab results repository There are 3 example RPs, RP A needs only immunization, RP B needs only lab results and RP C needs both. Using resource discovery each RP is registered with a ticket specific to the scope of their needs. In the last case, RP C can make one authorization request and may be granted access to both FHIR repositories Best, Alec Laws alec@identos.ca On Fri, Mar 13, 2020 at 8:07 PM Alec Laws <malcolm.laws@gmail.com> wrote:
Hi all,
Thanks for letting me share some of the extension thinking we’ve been going through at IDENTOS Hopefully the content below adequately describes the first of our changes (RS-first flows) to continue the conversation. Goes through some of the motivation, conceptually how it works,, and calls out items that are particularly different or have challenges being UMA compliant.
As many of you noted, in many ways this is a concept of a directory or trust-framework above specific AS/RS/Clients or the actual RO/RqP (intentionally excluding Alice/Bob)
Cheers! - Alec Ps More to come on privacy extension, the community vs personal authorization server and SSI alignment
# AS first flows/ RS discovery / Resource Server API Interoperability
General idea is that many RSs support a very similar API, eg FHIR/OpenBanking/Gitlab, so a Client _should_ be able to use any of those RS, as directed by the RqP. However, the 'very similar' part makes this difficult in practice. Ex two RSs could be FHIR R4, with a different vocabulary set such that the client can't actually use the APIs interchangeably.
We believe this is important as a user should have choice throughout the stack, currently choice exists at the Client and AS. Clients must know of/directly integrate to the RS, capping which RSs can be used with the client integration efforts.
Current State: UMA moves OAuth towards 'wide-ecosystems' by enabling AS interoperability. A RS can be protected by many AS, and an AS can protect many RS. From the Client's perspective, it only needs to know the RS it wants to access, and can "discover" the AS.
## How it works:
### Setup/Registration: 1. The AS defines general "resource definitions", This is an API standard reference with well defined scopes. - FHIR (scopes: sens/*, conf/*, patient, observation, ...) - FHIR - Patient - FHIR - Immunization - Userinfo - (scopes: first_name, email, birthdate, ...)
2a. Clients are registered with the AS for specific resource definitions - Client A can request a FHIR - Patient - Client B can request Userinfo (first_name), FHIR - Immunization, FHIR - Patient - Client C can request Userinfo (first_name, last_name)
2b. Clients are registered with "capability tickets" (static UMA permission tickets?) for different resource request sets - This could also be achieved in a more uma standard/dynamic manner where the client uses the Fedz Permission API with the general resource definitions - Client B can have a few tickets - "client-ticket-userinfo" -> Userinfo - "client-ticket-immunization" -> FHIR - Immunization - "client-ticket-patient" -> FHIR - Patient - "client-ticket-all" -> FHIR - Patient AND FHIR - Immunization AND Userinfo definitions
3. Resource Servers are registered with the AS for specific resource definitions and the endpoints where they are located - ex - RS X can provide Userinfo (first_name, last_name) - RS Y can provide FHIR - Immunization, FHIR - Patient - RS Z can provide All resources and scopes - The RS has a RO-independant PAT (RS=RO?) in order to introspect
### Client AS-first flow:
1. A RqP appears at Client A, the client needs access to a FHIR - Patient to provide some service 2. Client AS redirects to the AS claims_gathering with "client-ticket-patient" 3. The RqP authenticates (somehow) and can see RSs they can access: RS Y and RS Z - RO/RqP authentication and Alice-Bob delegation are out of scope, handled internally at the AS 4. The RqP selects the FHIR - Patient from RS Y 5. The AS redirects to the Client with a new permission ticket 6. The Client exchanges the ticket for a RPT, the token comes with a "resource_location=RS Y/Patient" - This could also use the token ‘aud’, however, that requires JWT and that the client inspect the token 7. The Client makes the request to RS Y with the RPT 8. The RS introspects the RPT to determine both resource and scopes it's valid for, and also which user/access it's for - The introspection was made with the general RS PAT. The response must include some other information about the specific Resource to access (in this example the specific Patient record) - This step has overlap with our other 'extension' around separating community from personal AS - Currently, when the RS is put under protection the RS/AS decide on a user subject. The AS returns that subject with the introspection so the RS can make internal determination about what specific data to return - Another alternative, when the RS is put under protection is it may register a user specific version of the general resource. During step 4 the RqP can select that specific resource. 9. The RS returns the resource to the client, or can perform the UMA WWW-Authenticate as usual
## Other Considerations:
- The client ticket can(?) have multiple resources, and _could_ end up needing the client to receive multiple RPTs? - If we enforce RS-restricted tokens - difficulty here in the format of the token endpoint… current support a normal token endpoint for RS-first and also a “packed” response that returns the multiple tokens if needed - this likely should be a different grant_type
- There is some notional alignment with OAuth resource indicators or PAR, haven't looked too deeply
Alec Laws 647 822 1529 alec@identos.ca
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma
I got both of your emails, fwiw, and they're in our archive: https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ZZ6H0QEaA1... *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Apr 30, 2020 at 7:31 AM Alec L <alec@identos.ca> wrote:
Hi,
Here are a few use-cases for discussion around RS discovery
The theme here is instead of all RPs needing to know about specific IDP/RSs, the the RP and RS are decoupled through an Authorization Server, allowing the SP to discover which RS to call after user authorization. This requires all RSs to support a standard API, claims_gathering and JWT tokens
## Use Case: IDP discovery, userinfo as a resource
Scenario: There are many similar IDPs which may provide standard profile data to a RP, through /userinfo endpoint There are many RPs that would trust any of those IDPs to provide profile data from a user
Using RS Discovery, an Authorization Server can manage the IDPs (as RSs) and _all_ RPs
Outcome: Reduce integration to only the AS for IDPs(asRS) and RPs - IDPs/RPs can still participate with many AS - user profile data isn't known to AS
Notes: Possible, but not nessecary, that the IDPs are an IDP to the AS. User login to the AS through one of the IDP
Similar solutions - yes.com which offers bank/idp discovery as a directory/dynamic-ish client registration to the specific IDP - gov.uk verify
Alternate Scenario: Even with a single IDP, that IDP can delegates RP onboarding to one or more AS
## Use Case: FHIR Repo Interop
There are several clinics which collect healthcare data and offer a simple portal to their patients. Many of the patients request to share their data with other applications. Instead of each clinic curating and vetting all application, they can delegate this to an Authorization Server
There are several [healthcare systems] that all support a [FHIR r4] API
## Use Case: Prevent Multiple Required Logins/Resources
An RPs requires a user to login to multiple IDPs to authorize an action (for legal/whatever reasons) OR an RP requires data from multiple RSs in order to provide a service
The AS can issue multiple access_tokens to the RP... and the RP can make API calls to both RSs with the appropriate constrained token
## Use Case: Data across FHIR Repos
A blend of the previous two use cases
There are many FHIR systems in a region. Each system maintains a specific subset of a patient record. For example there is an immunization repository and lab results repository
There are 3 example RPs, RP A needs only immunization, RP B needs only lab results and RP C needs both.
Using resource discovery each RP is registered with a ticket specific to the scope of their needs. In the last case, RP C can make one authorization request and may be granted access to both FHIR repositories
Best, Alec Laws alec@identos.ca
On Fri, Mar 13, 2020 at 8:07 PM Alec Laws <malcolm.laws@gmail.com> wrote:
Hi all,
Thanks for letting me share some of the extension thinking we’ve been going through at IDENTOS Hopefully the content below adequately describes the first of our changes (RS-first flows) to continue the conversation. Goes through some of the motivation, conceptually how it works,, and calls out items that are particularly different or have challenges being UMA compliant.
As many of you noted, in many ways this is a concept of a directory or trust-framework above specific AS/RS/Clients or the actual RO/RqP (intentionally excluding Alice/Bob)
Cheers! - Alec Ps More to come on privacy extension, the community vs personal authorization server and SSI alignment
# AS first flows/ RS discovery / Resource Server API Interoperability
General idea is that many RSs support a very similar API, eg FHIR/OpenBanking/Gitlab, so a Client _should_ be able to use any of those RS, as directed by the RqP. However, the 'very similar' part makes this difficult in practice. Ex two RSs could be FHIR R4, with a different vocabulary set such that the client can't actually use the APIs interchangeably.
We believe this is important as a user should have choice throughout the stack, currently choice exists at the Client and AS. Clients must know of/directly integrate to the RS, capping which RSs can be used with the client integration efforts.
Current State: UMA moves OAuth towards 'wide-ecosystems' by enabling AS interoperability. A RS can be protected by many AS, and an AS can protect many RS. From the Client's perspective, it only needs to know the RS it wants to access, and can "discover" the AS.
## How it works:
### Setup/Registration: 1. The AS defines general "resource definitions", This is an API standard reference with well defined scopes. - FHIR (scopes: sens/*, conf/*, patient, observation, ...) - FHIR - Patient - FHIR - Immunization - Userinfo - (scopes: first_name, email, birthdate, ...)
2a. Clients are registered with the AS for specific resource definitions - Client A can request a FHIR - Patient - Client B can request Userinfo (first_name), FHIR - Immunization, FHIR - Patient - Client C can request Userinfo (first_name, last_name)
2b. Clients are registered with "capability tickets" (static UMA permission tickets?) for different resource request sets - This could also be achieved in a more uma standard/dynamic manner where the client uses the Fedz Permission API with the general resource definitions - Client B can have a few tickets - "client-ticket-userinfo" -> Userinfo - "client-ticket-immunization" -> FHIR - Immunization - "client-ticket-patient" -> FHIR - Patient - "client-ticket-all" -> FHIR - Patient AND FHIR - Immunization AND Userinfo definitions
3. Resource Servers are registered with the AS for specific resource definitions and the endpoints where they are located - ex - RS X can provide Userinfo (first_name, last_name) - RS Y can provide FHIR - Immunization, FHIR - Patient - RS Z can provide All resources and scopes - The RS has a RO-independant PAT (RS=RO?) in order to introspect
### Client AS-first flow:
1. A RqP appears at Client A, the client needs access to a FHIR - Patient to provide some service 2. Client AS redirects to the AS claims_gathering with "client-ticket-patient" 3. The RqP authenticates (somehow) and can see RSs they can access: RS Y and RS Z - RO/RqP authentication and Alice-Bob delegation are out of scope, handled internally at the AS 4. The RqP selects the FHIR - Patient from RS Y 5. The AS redirects to the Client with a new permission ticket 6. The Client exchanges the ticket for a RPT, the token comes with a "resource_location=RS Y/Patient" - This could also use the token ‘aud’, however, that requires JWT and that the client inspect the token 7. The Client makes the request to RS Y with the RPT 8. The RS introspects the RPT to determine both resource and scopes it's valid for, and also which user/access it's for - The introspection was made with the general RS PAT. The response must include some other information about the specific Resource to access (in this example the specific Patient record) - This step has overlap with our other 'extension' around separating community from personal AS - Currently, when the RS is put under protection the RS/AS decide on a user subject. The AS returns that subject with the introspection so the RS can make internal determination about what specific data to return - Another alternative, when the RS is put under protection is it may register a user specific version of the general resource. During step 4 the RqP can select that specific resource. 9. The RS returns the resource to the client, or can perform the UMA WWW-Authenticate as usual
## Other Considerations:
- The client ticket can(?) have multiple resources, and _could_ end up needing the client to receive multiple RPTs? - If we enforce RS-restricted tokens - difficulty here in the format of the token endpoint… current support a normal token endpoint for RS-first and also a “packed” response that returns the multiple tokens if needed - this likely should be a different grant_type
- There is some notional alignment with OAuth resource indicators or PAR, haven't looked too deeply
Alec Laws 647 822 1529 alec@identos.ca
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma
Thanks for confirming. I received this email (and also get the weekly agenda) from wg-uma. Could be setup that I don’t receive my own posts Next time I’ll use the archive online to check! Alec Laws 647 822 1529 alec@identos.ca
On Apr 30, 2020, at 11:52 AM, Eve Maler <eve@xmlgrrl.com> wrote:
I got both of your emails, fwiw, and they're in our archive:
https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ZZ6H0QEaA1... <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ZZ6H0QEaA1k>
Eve Maler Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Apr 30, 2020 at 7:31 AM Alec L <alec@identos.ca <mailto:alec@identos.ca>> wrote: Hi,
Here are a few use-cases for discussion around RS discovery
The theme here is instead of all RPs needing to know about specific IDP/RSs, the the RP and RS are decoupled through an Authorization Server, allowing the SP to discover which RS to call after user authorization. This requires all RSs to support a standard API, claims_gathering and JWT tokens
## Use Case: IDP discovery, userinfo as a resource
Scenario: There are many similar IDPs which may provide standard profile data to a RP, through /userinfo endpoint There are many RPs that would trust any of those IDPs to provide profile data from a user
Using RS Discovery, an Authorization Server can manage the IDPs (as RSs) and _all_ RPs
Outcome: Reduce integration to only the AS for IDPs(asRS) and RPs - IDPs/RPs can still participate with many AS - user profile data isn't known to AS
Notes: Possible, but not nessecary, that the IDPs are an IDP to the AS. User login to the AS through one of the IDP
Similar solutions - yes.com <http://yes.com/> which offers bank/idp discovery as a directory/dynamic-ish client registration to the specific IDP - gov.uk <http://gov.uk/> verify
Alternate Scenario: Even with a single IDP, that IDP can delegates RP onboarding to one or more AS
## Use Case: FHIR Repo Interop
There are several clinics which collect healthcare data and offer a simple portal to their patients. Many of the patients request to share their data with other applications. Instead of each clinic curating and vetting all application, they can delegate this to an Authorization Server
There are several [healthcare systems] that all support a [FHIR r4] API
## Use Case: Prevent Multiple Required Logins/Resources
An RPs requires a user to login to multiple IDPs to authorize an action (for legal/whatever reasons) OR an RP requires data from multiple RSs in order to provide a service
The AS can issue multiple access_tokens to the RP... and the RP can make API calls to both RSs with the appropriate constrained token
## Use Case: Data across FHIR Repos
A blend of the previous two use cases
There are many FHIR systems in a region. Each system maintains a specific subset of a patient record. For example there is an immunization repository and lab results repository
There are 3 example RPs, RP A needs only immunization, RP B needs only lab results and RP C needs both.
Using resource discovery each RP is registered with a ticket specific to the scope of their needs. In the last case, RP C can make one authorization request and may be granted access to both FHIR repositories
Best, Alec Laws alec@identos.ca <mailto:alec@identos.ca>
On Fri, Mar 13, 2020 at 8:07 PM Alec Laws <malcolm.laws@gmail.com <mailto:malcolm.laws@gmail.com>> wrote: Hi all,
Thanks for letting me share some of the extension thinking we’ve been going through at IDENTOS Hopefully the content below adequately describes the first of our changes (RS-first flows) to continue the conversation. Goes through some of the motivation, conceptually how it works,, and calls out items that are particularly different or have challenges being UMA compliant.
As many of you noted, in many ways this is a concept of a directory or trust-framework above specific AS/RS/Clients or the actual RO/RqP (intentionally excluding Alice/Bob)
Cheers! - Alec Ps More to come on privacy extension, the community vs personal authorization server and SSI alignment
# AS first flows/ RS discovery / Resource Server API Interoperability
General idea is that many RSs support a very similar API, eg FHIR/OpenBanking/Gitlab, so a Client _should_ be able to use any of those RS, as directed by the RqP. However, the 'very similar' part makes this difficult in practice. Ex two RSs could be FHIR R4, with a different vocabulary set such that the client can't actually use the APIs interchangeably.
We believe this is important as a user should have choice throughout the stack, currently choice exists at the Client and AS. Clients must know of/directly integrate to the RS, capping which RSs can be used with the client integration efforts.
Current State: UMA moves OAuth towards 'wide-ecosystems' by enabling AS interoperability. A RS can be protected by many AS, and an AS can protect many RS. From the Client's perspective, it only needs to know the RS it wants to access, and can "discover" the AS.
## How it works:
### Setup/Registration: 1. The AS defines general "resource definitions", This is an API standard reference with well defined scopes. - FHIR (scopes: sens/*, conf/*, patient, observation, ...) - FHIR - Patient - FHIR - Immunization - Userinfo - (scopes: first_name, email, birthdate, ...)
2a. Clients are registered with the AS for specific resource definitions - Client A can request a FHIR - Patient - Client B can request Userinfo (first_name), FHIR - Immunization, FHIR - Patient - Client C can request Userinfo (first_name, last_name)
2b. Clients are registered with "capability tickets" (static UMA permission tickets?) for different resource request sets - This could also be achieved in a more uma standard/dynamic manner where the client uses the Fedz Permission API with the general resource definitions - Client B can have a few tickets - "client-ticket-userinfo" -> Userinfo - "client-ticket-immunization" -> FHIR - Immunization - "client-ticket-patient" -> FHIR - Patient - "client-ticket-all" -> FHIR - Patient AND FHIR - Immunization AND Userinfo definitions
3. Resource Servers are registered with the AS for specific resource definitions and the endpoints where they are located - ex - RS X can provide Userinfo (first_name, last_name) - RS Y can provide FHIR - Immunization, FHIR - Patient - RS Z can provide All resources and scopes - The RS has a RO-independant PAT (RS=RO?) in order to introspect
### Client AS-first flow:
1. A RqP appears at Client A, the client needs access to a FHIR - Patient to provide some service 2. Client AS redirects to the AS claims_gathering with "client-ticket-patient" 3. The RqP authenticates (somehow) and can see RSs they can access: RS Y and RS Z - RO/RqP authentication and Alice-Bob delegation are out of scope, handled internally at the AS 4. The RqP selects the FHIR - Patient from RS Y 5. The AS redirects to the Client with a new permission ticket 6. The Client exchanges the ticket for a RPT, the token comes with a "resource_location=RS Y/Patient" - This could also use the token ‘aud’, however, that requires JWT and that the client inspect the token 7. The Client makes the request to RS Y with the RPT 8. The RS introspects the RPT to determine both resource and scopes it's valid for, and also which user/access it's for - The introspection was made with the general RS PAT. The response must include some other information about the specific Resource to access (in this example the specific Patient record) - This step has overlap with our other 'extension' around separating community from personal AS - Currently, when the RS is put under protection the RS/AS decide on a user subject. The AS returns that subject with the introspection so the RS can make internal determination about what specific data to return - Another alternative, when the RS is put under protection is it may register a user specific version of the general resource. During step 4 the RqP can select that specific resource. 9. The RS returns the resource to the client, or can perform the UMA WWW-Authenticate as usual
## Other Considerations:
- The client ticket can(?) have multiple resources, and _could_ end up needing the client to receive multiple RPTs? - If we enforce RS-restricted tokens - difficulty here in the format of the token endpoint… current support a normal token endpoint for RS-first and also a “packed” response that returns the multiple tokens if needed - this likely should be a different grant_type
- There is some notional alignment with OAuth resource indicators or PAR, haven't looked too deeply
Alec Laws 647 822 1529 alec@identos.ca <mailto:alec@identos.ca> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/wg-uma <https://kantarainitiative.org/mailman/listinfo/wg-uma> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/wg-uma <https://kantarainitiative.org/mailman/listinfo/wg-uma>
participants (3)
-
Alec L -
Alec Laws -
Eve Maler