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:twb...@google.com] Sent: Thursday, 6 June 2013 1:23 PM To: Manger, James H Cc: oauth@ietf.org 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 <james.h.man...@team.telstra.com<mailto:james.h.man...@team.telstra.com>> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
