On 6/2/11 4:11 PM, Brian Eaton wrote: > On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre <[email protected] > <mailto:[email protected]>> wrote: > > I think I might have misunderstood that text -- I took it to be talking > about the client's authentication with the authorization server, not the > client's authentication with the resource server. > > > No, you understand perfectly. We're talking about giving extremely > powerful and near-permanent credentials to clients we can't > authenticate. We're pretty sure this is a good idea. =) > > We authenticate the user and get their consent. If they say yes, the > client gets something that is almost, but not quite, equivalent to an > alternate password for the user.
Sure, that's the classic OAuth pattern. I think the SHOULD we had originally is probably fine -- with the understanding that "SHOULD" means "you really ought to do this unless you have a good reason not to". I think one such really good reason might be a authorization server that doesn't allow unauthenticated clients (i.e., clients that are not pre-registered or don't have certificates or whatever). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
