Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

["Manger, James H" <[e-mail]>]

Your “first part” where a developer gets an initial token sounds like a task a developer does using only a standard web browser, knowing their developer password. There is no OAuth here; there is no app interacting (just a human at a browser).

Perhaps I should not have jumped into this thread as I have not been delving deep into registration. I guess it is conceivable that a fancy app development suite is acting as an OAuth client: directing the developer to the AS to authorize the development suite to contact the registration “protected resource” on the developers behalf. Once authorized, the development suite collects a token from the token endpoint. That token is the “initial access token”. That would be OAuth 2 for the first part.
--
James Manger

From: Tim Bray [mailto:[e-mail]]
Sent: Thursday, 6 June 2013 1:23 PM
To: Manger, James H
Cc: [e-mail]
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

I’m really missing something.  You start out with a scope you want a token for for, you get redirected for authentication, it comes back and you do a code flow or a browser flow and you end up getting an access token.  Smells like OAuth 2 to me.  -T

On Wed, Jun 5, 2013 at 8:19 PM, Manger, James H <[e-mail]<mailto:[e-mail]>> wrote:
Tim Bray wrote:
> FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful.
>
> - A developer manually registers and then is able to request “Initial tokens” tokens for a dynamic-app-registration-scope,
> - you use that “Initial token” token to register, in exchange you get the client-id & so on, and also a a per-registration “Registration token” for updating that particular registration information
> - you fetch/update/delete your registration information with that registration token.
>
> The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. (right?)
Wrong? This doesn't sound like it has any technical connection to OAuth 2. It is a developer browsing to a service portal; presumably logging in with a password, perhaps with a 2nd factor (no OAuth here); and manually copying a credential that can be used with the 'BEARER' HTTP Authentication mechanism. There is no app orchestrating the interaction (the developer just browsed to the portal); there is no programmatic exchange of one app credential for another at an AS token endpoint. The only technical connection to OAuth 2 is that the 'BEARER' HTTP authentication mechanism is branded "OAuth 2" for marketing(?) reasons.

--
James Manger