# 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