As of 02 Sept 2010, quorum is 6 of 10.
Non-voting participants:
Regrets:
Eve |
Open |
Follow up with Phil W. re holding a F2F meeting at IIW XI. |
|
|
All |
Open |
Review Domenico's wireframes and our recent emails with "scope" in the subject line, and weigh in with thoughts in email. |
|
Quorum was reached.
Sal's company, IDmachines, provides identity services to government and enterprise. He is involved in the US government's initiative around identity verification (such as PIV-I). He was formerly involved in CoreStreet.
Minutes of 2010-09-16 meeting APPROVED.
Thomas has enhanced the Introduction and Instructions section to include a template of "dimensions" and "building-block features" for which each scenario should provide a description. So far we have scope, cardinality, nature of host, dynamism vs. staticness, resource discovery, nature of access to protected resources, and person-to-self.
Eve wonders if the scope and nature of access to host ones can be combined somehow. And perhaps the person-to-self one can be renamed end-to-end or something.
The location scenario has been revised to include answers to the template.
Eve would like to see examples of real or imagined scopes provided in scenarios, and to see as much evidence of real-world scopes as possible (which, in the location case, is certainly possible) to inform our design process. Since she submitted this scenario, she should flesh it out more.
Regarding the cardinality dimension, can this be a discussion-starter instead of a "deterministic" topic? There are many aspects around cardinality that could be relevant.
Let's review the dimension template more over time, before we apply it to all of the scenarios thus far documented. We'll keep experimenting with scenarios 6, 7, and 11.
Eve had previously put together a speculative list of where the concept of scope impacts UMA.
This seems right.
In today's OAuth deployments, often the client, which has been statically provisioned with credentials, was told at registration time (out of band of OAuth) about what actions they could perform at that API. Christian comments that in Facebook, the client dynamically passes its desired scope during request time instead. Where scopes are openly documented, does it make sense for UMA – or even OAuth itself – to allow a requester/client to be explicit in telling the resource server/host what scope(s) it wants? For UMA, it would be more logical to do this when the requester approaches the AM (see just below).
The host has the privilege of saying what scopes are available, but the user has the privilege – through their policies – of saying who gets access under what conditions. So should the host have told the requester all the possible scopes that apply to that resource, so that the requester can choose what scopes to ask for? But this has security and privacy implications, e.g. in the case where the user's tagging of their photos might be revealed (unless the scope string obscures the actual tag, like "tag_restriction:abc123", but it maps to "pictures-of-waterfalls"?). Then again, for simple read vs. read/write access cases, this could be really useful. Perhaps, outside of the purview of UMA, a host can make available some user preference settings for sharing this. This sounds complicated, but we could allow the ecosystem to experiment with such features if UMA says nothing about what to do. We hope to be able to lean on generic OAuth for any processes where tokens are downgraded to handle lower scope and upgraded to handle additional scope (the latter requiring user consent), though.
So maybe the host is authoritative for telling the requester what scope(s) to ask for in order to have the best chance of success in getting an access token for those scopes, but if the host's API is well enough documented that the requester wants to try for more/bigger scopes, it can approach the AM with a different set. This would mean that the host is not responsible for making the scope information tamper-proof, which simplifies things considerably.
We discovered that we are still not sure that scopes should be a flat list, vs. a flat list of actions (with resources handled as a separate dimension – it was unclear from our discuss whether they would also have to be registered with the AM). We will focus exclusively on this issue next week.
(The rest of the proposed list is below, for the record; we didn't finish discussing it.)