I can agree with this. However if you keep client password (3.1) around I would prefer another section (3.x) that indicates "or any other client authentication method meeting the security requirements of the authentication server" to make it clear and easy to scan.
Phil [email protected] On 2011-01-18, at 10:06 PM, Eran Hammer-Lahav wrote: > Yes! This is exactly what I proposed if you combine removing Basic together > with the assertion credentials. Basically, provide the parameter based > approach as the only one specified, make it clear that *any* suitable client > authentication is allowed, and then use HTTP Basic as an example of such > other methods. I am even happy to explicitly mention the use of assertions > for client authentication in the prose. I just don’t think another > sub-section is needed. > > Would that be what you had in mind? > > EHL > > From: Phil Hunt [mailto:[email protected]] > Sent: Tuesday, January 18, 2011 9:23 PM > To: Eran Hammer-Lahav > Cc: [email protected]; Mike Jones; [email protected]; Karen P. Lewison > Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials > and OAuth2 HTTP Authentication Scheme > > 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
