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
