[WG-UMA] Partial draft of "scoped access" proposal based on focus call

[Eve Maler]

I'm hoping we can review this on the WG telecon shortly... Also note that I've been doing some work on rreg to match our decisions of last week, and I've experimentally pasted the HTML into the wiki here:

http://kantarainitiative.org/confluence/display/uma/UMA+Resource+Registration

It doesn't look perfect, but it's handy to have our real specs there.

(Christian, if you get a chance, can you please sync with all the new stuff in my github area and post the HTML and XML versions on clprojects? Maybe on today's call we can discuss whether the Confluence wiki version is sufficient; I'm willing to pump our HTML versions there instead of your doing it on your site.)

[Alan Karp]

Sorry if this comment has been superseded.  I searched the subsequent emails and didn't see anything on the topic.

I didn't have time to read the spec :(, but the description states, "Alice has already introduced this host to her AM, CopMonkey.example.com, and thus Photoz has already obtained an OAuth client ID and an UMA host access token from CopMonkey."  

It seems that the authentication requirement is in the wrong direction.  Photoz must know to trust access tokens issued by Alice's AM, but I don't understand why Alice's AM needs any specific information about Photoz.  I've been trying to think of a valid attack if Photoz does not have a client ID at Alice's AM, but I can't come up with any.  The best I can come up with is a malicious site that registers resources it claims are Alice's, but Alice would never point people to that site.  Is there only a denial of service, or is there some risk to Alice?

--------------
Alan Karp

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

[Eve Maler]

OAuth requires clients -- UMA hosts in this case -- to have client IDs. They could just be the string "anonymous" if that's what the AM will accept, but at this point we've decided to wash our hands of the question of how the ID is provisioned, at least as far as the UMA core spec is concerned. 

(We've proposed a spec that would allow for non-anonymous dynamic client self-registration to get such credential, but ultimately decided that the core spec shouldn't point out to it. Separately, the OpenID Artifact Binding folks have gotten quite specific about how such parties might mutually authenticate and learn about each other, which maybe someday we'll leverage.)

In the case of UMA requesters acting as OAuth clients, they also need client IDs -- which could again be anonymous or specific, but this is likely to have different security considerations than the host case because Alice doesn't necessarily get personally involved in the introduction.

Eve