[WG-UMA] Notes from 27 Jun 2011 UMA ad hoc call
Eve Maler
http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol
We didn't come to any really firm conclusions on open issues, but did push the ball forward a bit. Eve will produce a Rev 12 based on this for consideration on Thursday, and Maciej and Lukasz have quite a lot of "spec homework" as well...
* Need to fix two instances of "actions" that should be "scope" in Section 2.4.3. Also change the .../actions/... URIs to say scopes globally.
* Add a new ISSUE: One host registration endpoint or two, for resource set registrations and permission registrations?
* In Section 3 intro: s/none of the permissions associated with the token don't match the scope of attempted access/none of the permissions associated with the token match the scope of attempted access/ in the third bullet. Also, number the list items rather than use bullets, for ease of reference.
* ISSUE #32: Lukasz reports that OAuth doesn't specify enough to give us a hard answer here. We should specify that the host gives the requester a simple URI address for the AM that the requester then has to use to construct a hostmeta path and retrieve the metadata itself. This is what the SMART implementation does today, in fact.
* In Section 3.3.2, the group had discussed the idea last week of allowing the AM to return a subset of permissions based on the host giving it a filter. Can we combine this idea with the idea of approximating a PDP/PEP model more closely, where the host effectively says in its request to the AM, "The requester is attempting access that requires one of these resource sets/scopes; can you please return all of the permissions that are still valid that match any of these?" and if the AM's response isn't empty, then it's tantamount to saying "Yes, the requester has sufficient permission" if the host agrees. Maciej and Lukasz have begun the process of putting together JSON examples, so they'll include this in the set.
* Lukasz has begun working on the new error message content.
* ISSUE #28 (which Eve added in Rev 11): Okay to require the AM to support the authorization code grant type, in addition to optionally supporting the SAML bearer assertion grant type, to give a baseline of mandatory-to-implement functionality? Lukasz thinks it makes sense to add this conformance requirement.
* ISSUE #30 (which Eve added in Rev 11 but it's really an "old issue"): We say the {hostid} has to be the client ID, but what if the host is in the position of using anonymous credentials for some reason? Is that even a possibility in the case of hosts (vs. requesters)? Should we identify this more obviously as a constraint? In SMART, they use the client ID as the host ID, and it would seem that the AM should know the instance of the host that is accessing it. So we should state this as a constraint/requirement on the introduction process.
* ISSUE #31 (which Eve added in Rev 11): Should the response to creating or updating a resource set description play back the just-registered description? See how SCIM works for an example of this. Lukasz has no strong opinion on this.
* ISSUE #32 (which Eve added in Rev 11 but it's really an "old issue"): Need to add back detail on how the host tells the requester which AM to go to so that it can discover the token endpoint and authorization endpoint. The message examples that will be provided by Lukasz and Maciej will flesh this out.
* ISSUE #33 (which Eve added in Rev 11): Should it be possible to have an "implicit resource set" somehow that (in syntactic-sugar fashion) allows permissions to be passed around much as scopes already are passed around in plain OAuth? Eve suspects that the host must register _something_ explicitly, even if it's an "all resources" special case. On Gallerify.me, for example, the user needs to hit the "Share" button, but in some other more tightly coupled environments, the host might unilaterally decide (or be instructed on the back end by other processes than the user themselves) to register some or all resources that this user has operative control over. However, the host (as usual) has to be able to disambiguate which user has that operative control.
* ISSUE#08: Sort out whether resource set descriptions are supposed to use scope URIs or scope identifiers! It's inconsistent now. We can close this now; Rev 11 fixed this.
* ISSUE#09: Move the resource registration API section to be a subsection under the previous big section. We can close this now; Rev 11 fixed this.
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma