Page Comparison

...

• Alternate Thursdays 6:30am PT (this ad hoc meeting was added in the series specially)
  • Screenshare and dial-in: https://global.gotomeeting.com/join/857787301
  • See UMA calendar for additional details: http://kantarainitiativekantara.atlassian.orgnet/confluencewiki/display/uma/Calendar

Agenda

• IDENTOS extensions
• Interop

...

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 week/2 - weeks - from - now weeksetc. No one attending today has a problem. Eve will investigate with others and voting participants who are not currently present and reschedule if no problem. (UPDATE: Sufficient positive responses established, so Eve will switch weeks in the calendar. We will start meeting Apr 16, Apr 30, etc. instead of continuing with Apr 9, Apr 23, etc.)

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. IT budgets seem overall negatively impacted in the current environment, though this is not evenly spread out. UMA and delegation use cases generally depend on identity solutions being in place, so that makes them relatively "sophisticated". On the other hand, telehealth and health data sharing are under more pressure now.

IDENTOS extensions

...

Alec provided a sequence diagram

...

@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

and we worked through it. To download, see the attachments to this page.

Image Added

The resource IDs are static.

...

Is the capability ticket similar at all to "OAuth resource indicators "(now RFC 8707)? 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 IDENTOS has implemented a dynamic version along with their static version, but they're not currently using it.

Alec provided three flows The first flow in the diagram .The first flow is "standard UMA", RS first. The client RS can still request a permission ticket, only using static resource IDs. The last leg is always a token endpoint call with either form of claims collection.

The second flow is the static capability ticket flow. It The client goes to the AS first and then goes straight to interactive claims gathering. The RqP (currently the same person as the RO) 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 it was the RS. This is perhaps a bit like OAuth Pushed Authorization Requests (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. (Last week Alec noted that it was in this step, providing the subject, that there is some potential overlap with the other extension they have defined. See his email to the list and the description of "step 8" for more detail.)

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).

...

• 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]play

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

Interop

tbsDeferred, but some people are working on this as a separate thread.

Attendees

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

...