Eran, Yes, I agree it feels like we're going in circles. Might I point out who it was that started this round? ;-) Still, I think the discussion is useful and important.
3.0 introduces the concept (that any client authentication is acceptable) but then specifies 2 acceptable methods (3.1 and 3.2) and leaves out other forms of client authentication. The specification can be interpreted that the "any types" of methods supported are 3.1 and 3.2 ONLY. It just seems that the current spec has awkward phrasing. My suggestion was simply to drop client_assertion and replace with some text indicating what "any client authentication" is. Assertion based authentication would then be supported via the new paragraph 2 which allows for any kind of client authentication (SAML, Kerberos, STS, whatever). Just to add another loop, what about cutting out the entire section 3 and keep client_id as a required parameter in 4 and 5 (related to but not directly tied to authentication) -- and getting OAuth out of authentication methods entirely (other then to specify it as a requirement)? Phil [email protected] On 2011-01-18, at 8:23 PM, Eran Hammer-Lahav wrote: > Thanks Phil. > > The problem with this text is that it doesn’t add anything new and I am not > sure what Client Web Credentials even mean. > I have argued against under-specified features and will continue to object > their inclusion. When I initially agreed to include Yaron’s text for client > assertion it was based on the assumption that it will provoke discussion and > will mature into a fully baked feature. It has not. Instead, it sits there > without enough details to produce even a single working implementation, not > to mention any level of interoperability what-so-ever. > > The specification clearly allows any kind of client authentication. How is > that not enough? How is providing two parameters that are useless without > further profiling in any way useful? If you need stronger alternatives to 3.1 > you are very welcome to define and publish such in companion specifications. > It feels like we are going in circles where a few people are arguing to keep > a feature that does not accomplish their reasons for its inclusion. > > EHL > > From: Phil Hunt [mailto:[email protected]] > Sent: Tuesday, January 18, 2011 2:45 PM > To: [email protected] > Cc: Eran Hammer-Lahav; Mike Jones; [email protected]; Karen P. Lewison > Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials > and OAuth2 HTTP Authentication Scheme > > (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
