Page Comparison

...

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

...

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

...

We seem to have interest in continuing 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)

...