...
Minutes
Roll call
Quorum was not ? reached.
Approve minutes
Approve minutes of UMA telecon 2016-11-10: tbsDeferred.
Logistics
tbsThe agenda is starting to include even the minutiae of the issue backlog and the roadmap. It looks long, but is designed to keep us honest in gaining consensus on discussion topics. If people show up to meetings and review spec drafts, we'll push through everything on a good schedule.
No meetings next week.
Work on UMA.next issues
...
The RReg definition of a protected resource goes too far because it presumes an RO. If we soften it to mention just an AS, then we think that the RReg spec is generic enough to serve OAuth needs along with UMA etc. needs. Let's try that.
Eve asked an aesthetic question about the sample endpoints in the config response. If anyone would like to see them looking different send mail with your preference.
The entire abstract and Introduction are new (and is awaiting a new ASCII diagram). PLEASE review and comment.
Discussion of Eve's strawman proposal: James likes the idea because, what if you want to mix UMA and OAuth scopes? You can't expect a client to maintain multiple access tokens where there are AS's supporting multiple grant types that deal with incompatible tokens. This is where getting Implementer's Drafts out there would be really useful. You could include OAuth scopes in an RPT now with no UMA permissions, but the permissions property would still have to appear with nothing in the array; that's ugly.
If the AS gives the RS a locally validatable RPT, normally the format of the token would be considered in the realm of a "private communication" between them, and it would be considered a burden to impose constraints on that. In the interest of making possible the new Intro text's promise that "The token introspection extension lets the resource owner increase and decrease grants at a grain finer than a whole access token.", do we want to say that the AS MUST/SHOULD/MAY package up locally validatable RPTs as signed versions of the token introspection object? Maybe we just point this out; it's the obvious object to sign if you want that functionality.
AI: James: Send a note to the list about the question of a locally validatable RPT and whether to recommend something about its format.
What scopes should the client ask for, and why? The client knows nothing about resource IDs and in particular nothing about any of the resource IDs associated with the permission ticket it just brought to the AS, only about the API and presumably about the scopes possible on the HTTP resource to which it just attempted access. This client-AS request is the first step in the UMA grant, and we can tell because the client is coming to the token endpoint with a permission ticket. Let's say the ticket has R1, R2, and R3. They all have "view" available, and R2 and R3 have "print" available. There are OAuth-protected resources at the same RS that have scopes that overlap. Is it possible to have a hybrid client-AS request at this stage? Is it possible to be executing two OAuth grants at the same time? Eve hasn't heard of this before, and we do already have an invalid_scope error in place to protect against scope clashes of the sort imagined. This may mean that our hybrid UMA-OAuth scenario above wouldn't work anyway.
AI: Eve: Send a note to the list laying out the current situation wrt scopes.
Instructions:
- RReg 02: Soften "protected resource" definition and any similar passages to remove the insistence that an RO is required for protection to obtain over a resource.
- Implement the token introspection proposal.
- Sketch a Sec 1 Intro diagram.
- Revise the Sec 3 intro and sketch an ASCII diagram for it.
Attendees
As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)
- Eve
- tbsMaciej
- Sarah
Non-voting participants:
- James
- tbsArlene
- Kathleen
Regrets:
- John W
- Sal