...
- Roll call
- Approve minutes of UMA telecom 2016-06-23
- For reference: MPD sequence diagram and generic low-level sequence diagram
- Registering multiple resource sets
- Input from George on existing spec text?
- Client awareness of scopes
- Concrete proposals based on multiple-resource-set directions?
- AOB
Minutes
Roll call
tbsQuorum was reached.
Approve minutes
Approve minutes of UMA telecom 2016-06-23: tbs
Registering multiple resource sets
tbs as amended to reflect Andi regrets: APPROVED.
Breadth-first MPD review
The client request that (potentially) includes scopes is now form-encoded vs. JSON, to align more closely with OAuth.
If Alice's policies say that the client is able to get access (e.g., because it pushed sufficient claims about the RqP that matched the RO's policies and the particular identified client is okay), then the AS could issue an access token right away. This is the final choice outside the loop.
Inside the loop, there are now two choices, vs. three, since there's no AAT. The AS rotates the ticket every time it returns a response to the client, and gives it need_info (with new syntax). The client either "sends claims" to the token endpoint, or "sends the RqP" to the claims endpoint.
With the AAT in the picture, UMA had an in-band way to let the RqP permission the pushing of claims (about them) to the AS. What happens now? We discussed what uma_authorization scope really means. Although UMA Core says "The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server", is it strictly true that Bob would know this in practice? Would UX standards have to be put in place in deployments? Since the AAT was covering an unspecified set of claims, Justin is suggesting that an AAT was insufficiently granular to inform Bob about what was going on. Can we assume the wonderful circumstance that Bob's relevant claims are UMA-protected and therefore the "out-of-band" protection circumstance is ideal for fine-grained protection with Alice's AS?
A typical case, we expect, is a SSO-like pattern where the information the AS needs is pre-negotiated with the client. In the case of a "promiscuous client" that is set up to share a lot of information about Bob, the interactive pattern could be used as a flow to get Bob to approve of, confirm, or consent to sharing that would otherwise happen silently. This would exploit two parts of the loop. If we want to ensure this pattern is available as a regular thing, Bob would get redirected to the claims endpoint at the AS, where Bob has to choose some claims provider that can supply a claim about accepting the client as representing him. The "non-in-band" experience is totally silent = smoother. The "in-band" experience involves a redirect to the AS and then to a claims provider = equal to the current AAT experience if there is a local login, or possibly more involved if there's choice about where to go to get the claim (Eve believes this is true; Justin disputes it). There are now the two options. Will clients have the incentive to go for the smoother option (and will "UMA protection" arise for this)?
AI: Justin: Write up answers in email to the questions above.
Another question: When the RqP = the RO (that is, it's Alice-to-Alice sharing), how would the loop work?
(We closed the formal WG call and continued discussing.)
Right now, the RqP's identity is bound into the AAT. But without the AAT, the client wouldn't have that available. As long as we can provide an identity token in a client-authenticated call, George asks, isn't there a way to solve this? Eve's question is about the use of the claims endpoint vs. the authorization endpoint: If it's Alice, shouldn't she use the latter? Only if it's OAuth vs. UMA. Alice-as-RqP should use the claims endpoint.
George wants a strong proof of Bob. The AAT gave him that, so whatever future mechanisms need to not lose that. Also, the AAT made the semantic of identity (and approval) persistent across a single transaction or session. We discussed how, in the current UMA flow, the client is able to pass in the current RPT to get the next one; we could leverage this pattern in order for the client to provide "Bob context" to the AS at the token endpoint.
Another question: We know that the trust elevation mechanism is gaining attention as a place for extension. How should we ensure this going forward?
Logistics (discussed post-official call)
Since we're once again in design mode, we should strongly consider expanding our meetings to 90 minutes. Would 8:30-10am or 9-10:30am PT be better for people?
Attendees
As of 23 Jun 2016 (post-meeting), quorum is 6 of 11. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah)
...
- Domenico
- Kathleen
- Nagesh
- Andi
- Maciej
- Eve
- Sarah
Non-voting participants:
- tbsFrançois
- John W
- James
- Scott
- Justin
- Ishan
- George