Eran, >>> What does scheme=basic mean [in a token response]?
> But that has the same security properties as bearer. True. >> Keeping [type and scheme] separate... >> It just means we need another registry (of token_types, with associated >> procedures); and we need an extra spec for each authentication mechanism >> to define the linkage to OAuth2. > Yeah. But I'm not expecting a flood. We'll have a handful and probably 2 will > survive the deployment test. OAuth 1.0a had three signature methods and only > one really got any significant traction. Its not a flood of schemes I am concerned about, but providing a clear mental model. It is less obvious how delegation and HTTP auth go together when one uses "type" and the other uses "scheme", with any connection between the two left to a case-by-case description. >> A lot of authentication mechanisms take similar inputs (an id and a secret) >> so >> they shouldn't each need a separate spec to define their binding to OAuth2. >I don't see a way around it. OAuth returns tokens using form-encoded URI and >JSON body replies. If your token is not self describing, you need extra >parameters so binding is required anyway. It is a pity the form-encoding isn't a base64url-encoded version of the JSON body reply isn't it :-( >>> I am using 'MAC' for my draft. >> >> As the token_type? As the HTTP authentication scheme? I hope both. > > In my case both, but I don't care about it as a generic HTTP authentication > scheme. It can be used that way but it is defined in clear OAuth context. My guess is that it would be easier to understand a standalone MAC HTTP auth scheme, than have to understand it amongst the complexities of delegation/swapping-perm-cred-for-temp-cred/swapping-assertion-for-temp-cred/etc. I am looking forward (with some trepidation) to seeing the MAC scheme in your current project. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
