UMA telecon 2020-08-06

Date and Time

Primary-week Thursdays 6:30am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/485071053
- United States: +1 (224) 501-3316, Access Code: 485-071-053
- See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Approve minutes of UMA telecon 2020-07-09, 2020-07-16, 2020-07-23, 2020-07-30
PKCE + ICG considerations
- Per Alec's email
Relationship Manager profile
- Taking into account/defining terminology, e.g. whether we should define "self-sovereign" and/or "cascading" AS's as part of the topology choices, per Adrian's thread
AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Approve minutes of UMA telecon 2020-07-09, 2020-07-16, 2020-07-23, 2020-07-30

Deferred.

PKCE + ICG considerations

Per Alec's email

Is PKCE the right tool for the desired security job? PKCE is a way to ensure that only the specific app instance is capable of finishing the authorization code flow when you're using a public client. The UMA permission ticket acts like an authorization code. iOS does PKCE particularly nicely. Public clients are easy to impersonate, even with PKCE. App attestation could help. Alec's use case is a native app. PKCE has some nice benefits in other cases too, such as CSRF. But if you have a first-party app and you have turned off consent, it can do OAuth/OIDC with itself using PKCE, and there can be silent escalation of privilege to a more-privileged app through PKCE. The attacker impersonates the first-party client. Universal links through app links gives more protection in this case. In the SSI context, wallet-based authentication that has been kicked off through a QR code pairing is the "strong auth" answer. PKCE is meant to be protection in the case of redirect flows, but SSI doesn't have redirects. GNAP tries to avoid redirection through the front channel, but we think it doesn't totally avoid it. In any case, our current inquiry is about whether we can – or should – just sort of pick up PKCE and use it with "today's UMA2" given that it uses "today's OAuth2" (or potentially OAuth 2.1), essentially without other change.

George suggests that there is no harm in using PKCE regardless. Alec is suggesting that we use it on redirection. The question might be about if we would want to use it if redirection is used for multiple claims-gathering cycles. Does it actually help in that case? We probably want to recommend it when the client we are redirecting to in the callback URL is public (can't protect a secret) – or if the callback URL can't otherwise be bound 100% to a given app. UMA doesn't disallow any particular OAuth extensions (e.g. around dynamic client registration). Here is what OAuth 2.1 currently says about applying PKCE.

Where should we document this discussion? The UIG for now, but maybe we need something like a BCP or Security Considerations outside the spec by now. And there has been a conversation about more cross-industry security profiling lately, so we should look out for that.

AI: Alec: Write up a new PKCE Guidelines section and insert it into the UIG.

Regarding DCR, doesn't HEART require it? We think so. (Eve is not going to look this up right now.) That question wouldn't be strictly about security profiling, since different deployment communities might feel differently about it.

Relationship Manager profile

Taking into account/defining terminology, e.g. whether we should define "self-sovereign" and/or "cascading" AS's as part of the topology choices, per Adrian's thread

Let's use a use case of Alice with photo resources, wanting to share them with Bob on the basis of his being able to provide a claim saying he is Bob.

In the use case of Bob protecting his claims-to-be-used-to-access-Alice's-UMA-resources with UMA (can we call this "trusted claims" or "well-protected claims" or something like that now, for clarity?), we think he can be both an UMA RO and an UMA RqP only in the case that ICG is used. If claims are pushed, then Bob's claims will have been gathered "off-stage" somehow. The relevant privacy consideration is documented in UMA Grant 6.2: The AS will see Bob's claims to satisfy Alice's policy, so unless there is a trust framework covering how to protect them, it's best to use ICG and ask for his consent. The legal role definitions spaghetti diagram shows how Bob, as a Requesting Agent, delegates the authority to seek access to the Client Operator and licenses the getting of permissions to the. Authorization Server Operator.

But using UMA to protect his claims and give him his own "policy power" would be even better than mere opt-in style consent, wouldn't it? How would "just" consenting even give him the ability to meaningfully license permission getting? We want to be able to do better than that.

Could we incorporate the relationship manager app's "legal role" into the spaghetti diagram somehow? What changes would need to be made to our model?

Adrian asks: Can Bob protect his claims with nonrepudiable signatures?

Attendees

As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike)

Michael
Domenico
Sal
Andi
Eve

Non-voting participants:

Scott
Alec
Adrian
Patrick
Tim
George
Lisa
Colin
Nancy

Browser not supported