James, thanks for the review.
On 06/06/2013 12:06 AM, Manger, James H wrote:
BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is
deliberately extensible to support other sorts of credentials (eg MAC
authentication).
Why is draft-ietf-oauth-dyn-reg hardwired to only support BEARER tokens?
1.3. "Registration Tokens and Credentials" says:
"The Initial Access Token ... is an OAuth 2.0 Bearer Token"
That should probably say OAuth 2.0 Token there -- I see no reason to
constrain the Initial Access Token to be a Bearer.
"The Registration Access Token ... is an OAuth 2.0 Bearer Token"
This, however, makes sense -- it's a shared secret between the server
and the client for use with registration. Do we have a mechanism for
passing dynamically allocated shared secrets around on HTTP calls? Yes:
Bearer tokens.
Google's TLS ChannelIDs [draft-balfanz-tls-channelid], for instance,
would be a fantastic fit for linking the first registration request
with any subsequent registration modifications. The Registration
Access Token would be annoying legacy baggage in that situation.
Wouldn't all OAuth tokens be "annoying legacy baggage" then?
It seems that the Registration Access Token is only ever used at a
single URI: registration_client_uri. That sounds like the perfect
situation to use a "capability URI", effectively putting the token in
the URI. Anyone considered doing that? It should significantly
simplify the spec.
That would require servers to be able to differentiate clients based on
the URI, and we got feedback from people that wanted to have the Client
Configuration Endpoint served on a single URI so that the server
wouldn't have to track and map different clients to different URI (see
Tim's recent comments even). Separating the URI from the Authorization
like this, using existing mechanisms, makes that possible.
-- Justin
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
