Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

UMA telecon 2020-04-02

Date and Time

Agenda

  • IDENTOS extensions
  • Interop

Minutes

Which week to meet

George points out that the "OpenID A/B" (OpenID Connect) meeting overlaps the latter half of this meeting if we meet last/next week vs. this/2-weeks-from-now weeks. No one attending today has a problem. Eve will investigate with voting participants who are not currently present and reschedule if no problem.

Online notarization

Tim raises the topic of the current worldwide situation and the fact that online notarization has suddenly become more important. Is this similar to remote proofing? These technologies have certainly existed for quite some time, and have been integrated to IAM stacks. But it got more notice in Okta's keynote this week, which mentioned use cases like employee onboarding.

IDENTOS extensions

We have a sequence diagram to look at this time.


@startuml


actor ASO
actor RqP
participant Client
participant AS
participant RS

ASO -> AS: add resource defintitions + scopes
...




RS -> AS: register as oauth client
RS -> AS: register to provider resources + scopes : static resoruce ids
RS -> AS: get RS PAT


...


Client -> AS: register as oauth client
Client -> AS: register to request resources + scopes
Client -> AS: register a capbility (set of resources) : static capbility ticket

...

RqP-> Client: service request




alt standard UMA, RS first


Client -> RS: request resource
RS <-> AS: POST /permission(resid) : ticket
RS -> Client: WWW-Authenticate(ticket)


Client -> AS: POST /token (ticket) "token pushing/claimsgathering"

else FPX AS first (static ticket)



Client -> AS: 302 /claims-gathering


RqP -> AS: authn + authz


AS -> Client: redirect_uri (ticket)



else FPX AS first (Client facing permission endpoint)


Client -> AS: POST /client/permission : ticket


Client -> AS: POST /token (ticket) "token pushing/claimsgathering"


end


Client <-> AS: POST /token(ticket) : access_token(s)


Client -> RS: /resource (access_token)


RS -> AS: POST /introspect (access_token)


AS -> RS: { permissions, subject }


RS -> Client: {resource}

@enduml



The resource IDs are static.

The "RS PAT" is not RO-specific.

The capability ticket is static. If you want to see a patient record with an immunization, you get a capability ticket that's sort of like a permission ticket but it doesn't change. This maps to terms of use. When a RqP authorizes the client to access resources and scopes, they review the ToS. This is Alice-to-Alice sharing right now. So the effect is Alice reviewing ToS for accessing her own stuff. What is in this ToS? It's the client's ToS for usage by the RqP, whoever it is (could be Bob in future). The client uploaded this to the AS for safekeeping, effectively. So the AS presents the ToS to the RqP on the client's behalf. Thus, instead of the possibility of the RqP having an independent relationship possible with that client outside of UMA and that AS, the RqP is assumed to use the same AS as the RO does, so it's a narrow ecosystem assumption. (See slide 36 in the UMA Legal role definitions for the "RqP-CO-ASO relationship train tracks" for how it could be built up in the widest possible ecosystem.)

Security-wise, is it okay for the capability ticket to be static? It's like requesting a scope, so it's okay for it to be static. So yes, it's safe. George describes the critical characteristics: If it's just an identifier, it's okay to be static. If it's a "binding agent" across multiple flows, then it needs to be rotate.

Is the capability ticket similar to "resource indicators"? It's more general, but the analogy does apply. The client would use the resource definition in the URI instead of the resource server.

What happens if the API gets versioned? Is there a CRUD API or something? The capability API has something like the resource registration API. They have a dynamic version along with their static version, but they're not currently using it.

Alec provided three flows in the diagram.

The first flow is standard UMA, RS first. The client can still request a permission ticket using static resource IDs. The last leg is always a token endpoint call.

The second flow is the static capability ticket flow. It goes straight to claims gathering. The RqP is then at the AS after the redirect and can authenticate etc.

The third flow is a hybrid where the client, not using the static capability ticket, uses the permission endpoint as if they were the RS. This is perhaps a bit like PAR. Are there any security implications to this? The client is similar to an RS in that they have registered what they can do. Since a PAT is now no longer RO-specific, the client can go ahead and use their client credentials as a "PAT-equivalent". The AS can distinguish them from an RS because they have registered as a client.

After the three flow options, saying (say) that they're looking for a patient record, now the RS still has to be told which patient's resource to give out. So in introspection, the AS provides subject information explicitly in its response, along with the granted resource IDs and scopes. Or George notes that an encrypted access token could contain that information. The RPT is still used.

Thank you to Alec and IDENTOS for contributing this for the WG's consideration! The "narrow ecosystem" this use case serves does seem pretty common (shared AS between the RO and RqP, oftentimes the RO == the RqP, the design patterns of the resource need interop due to open APIs or other reasons).

Other questions and comments we didn't have a chance to address yet, maybe in future:

  • George: Could you use Dynamic Client Registration of the mobile app to help with this? That would make the client_id specific to each mobile app instance
  • Sal: trusted platform environment might also come into play [TPM]

We seem to have interest in continuing work on this as a WG. More to come.

Interop

tbs

Attendees

As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike)

  1. Domenico
  2. Sal
  3. Eve
  4. Mike

Non-voting participants:

  • Cigdem
  • Scott
  • Alec
  • Tim
  • George
  • Colin


  • No labels