(apologies if this is a re-post, for some reason it was previously bounced)
I've been arguing as well to keep client assertion or some other stronger alternative to 3.1. Re-reading the introduction to section 3, I see that the last paragraph says: The authorization server MAY authenticate the client using any appropriate set of credentials and authentication schemes. The client MUST NOT include more than one set of credentials or authentication mechanism with each request. I would suggest the following. That we replace 3.2 with this paragraph expressed as an alternative (move it from the introduction and a little massaging). The idea would be to make it clear that using normal web authentication methodologies is perfectly acceptable. Further, I would also suggest that if an OOB authentication is use (and preferred), that the client_id might still be sent. This handles case where mapping between client_id and the client credentials is not obvious (or easy). How about: 3.2. Client Web (OOB) Credentials The client MAY be authenticated using any appropriate set of credentials and web authentication scheme supported by the authorization server. In cases where the client_id cannot be mapped by the authorizing server from the client credential, the client_id MUST be provided.[should client_id always be provided?] I would even include language that makes Client Web Credential authentication the preferred methodology or at least list it first. This makes the spec more consistent in that OAuth is not involved in the authentication of the user or the client. -- it makes it more consistent. This approach will allow assertion based authentications (SAML, STS, etc) or other approaches without having to get hung up on how it should work inside of OAuth. Phil [email protected] On 2011-01-18, at 12:26 PM, Francisco Corella wrote: > Mike, > > As assertion use is described in the spec, a client assertion does not > provide any security whatsoever. How do you handle subject confirmation in > your implementation? (See section 2.4.1.1 of the SAML specification.) In > other words, how does the authorization server know that the client sending > the assertion is actually the subject of the assertion? > > Francisco > > --- On Tue, 1/18/11, Mike Jones <[email protected]> wrote: > > From: Mike Jones <[email protected]> > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and > OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" <[email protected]> > Cc: "[email protected]" <[email protected]> > Date: Tuesday, January 18, 2011, 5:35 PM > > Having spoken to a number of people implementing the spec here, I’ve > encountered strong objections to removing Client Assertion Credentials and > the OAuth2 HTTP Authentication Scheme. It’s also not clear to me why we > would make substantial breaking changes to the specification when it is > essentially ready for approval. I’ve summarized the reasons I believe we > should keep these two features below. > > > Client Assertion Credentials: Many of the scenarios we care about require > this capability. They were key motivators for the Assertion Profile in WRAP > (see § 5.2), have been part of OAuth 2 for quite a while, and we have running > code that requires this support. For example, the Azure Access Control > Service is a cloud Authorization server that supports several protocols, > including parts of OAuth 2.0 draft 10 (autonomous and web server profiles). > We are happy to update our implementation to subsequent drafts & agree that > the spec leaves a lot of ambiguity. > > > In our implementation of the autonomous and web server profiles, ACS allows > clients to authenticate using a signed assertion as well as with a > username/password. The username/pwd option is for clients that don’t mind > sending credentials over the wire, while the signed assertion mechanism is > for clients that are more reticent to send raw credentials and for scenarios > where it isn’t possible. To illustrate an example where username/pwd isn’t > viable, consider the case of a client that needs to use an enterprise > identity to gain access to a cloud service. In many cases, corporate policy > demands that a client use an identity managed by the organization. This means > that the client should obtain an assertion from an enterprise identity > provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an > access token which grants access to various web service APIs. Many of our key > MSFT customers and internal partner teams rely on this mechanism and > reverting exclusively to username/pwd isn’t an option for us. > > > 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like a > huge step away from interoperability. As one data point, Microsoft > implements this in our WIF OAuth2 protected resource code. All up, clients > need a way to authenticate to the protected resource. Also, existing WRAP > implementations need this functionality to migrate to OAuth2. For all these > reasons, we support retaining this functionality in OAuth2. > > > Thanks, > > -- Mike > > > > -----Inline Attachment Follows----- > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
