Re: Use case classification, and associated security models

In general, I agree with the 3 classes of the API, as well as Ryan's views on naming, below. At least in version 1 of this API, I feel it very difficult to double guess (and thus limit) what the apps would need. The less restrictive the API, IMO, the more we would have erred on the side of usability. For example, the API can make the name optional, thus if not provided by the JS, the API can generate one and return it.

I think that the overall security of the API is still through origin-check. A key stored by script originating from one domain can only be accessed by (the same or another) script originating from the same domain. We can think of further restricting the access similar to cookie domain and path attributes. So, the script storing the key can specify such restrictions.



Seetharama



From: Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>>

In this formulation, what is the advantage of a UUID over an opaque string supplied by the application (which may be a UUID, or may be a string such as the simple English string "NetflixAuthKey")

My thought is that whatever naming scheme we go with, it should be:

 *   Entirely up to the implementing application/web site how it wants to refer to keys. That is, it can dictate the key name itself.
 *   Entirely scoped/bound to the current security origin. That is "NetflixAuthKey" at netflix.com<http://netflix.com> may represent a completely different key than "NetflixAuthKey" at netflixcdn.com<http://netflixcdn.com>.

This then opens two new desired behaviours:

 *   Users may wish to re-use the same key under the same name or different name between origins (eg: the scenarios #1 and #2 I gave for Alice and Bob)
 *   Site operators may wish to share the same key under the same name between different origins (eg: the netflix.com<http://netflix.com> and netflixcdn.com<http://netflixcdn.com>, both entities presumed operated by Netflix, that both wish to perform some keying operation)

>From the perspective of the application consuming the API (eg: doing operations with the keys), a key handle is a key handle. The above scenarios only come up with key discovery. However, whether the key's provenance is via Scenario #1, #2, or #3, and whether it's a shared key, unique-per-origin, or pre-provisioned, is something largely transparent at the API layer outside of discovery.