Hi Eran, 
Hi all, 

I would like to start a working group last call on the base specification soon 
and the writeup in Section 3.2 about the Client Assertion Credentials is, 
unfortunately, not ready yet. Particularly the missing security discussion 
scares me. 

Hence, I would encourage someone to take the text from that section and to 
produce a new draft that also includes a reasonable security description. Do we 
have a volunteer?

Ciao
Hannes

On Jan 15, 2011, at 8:45 AM, Eran Hammer-Lahav wrote:

> I would like to suggest we drop the client assertion credentials (-11 section 
> 3.2) from the specification, and if needed, publish it as a separate 
> specification for the following reasons:
>  
> 1.       The mechanism is under specified, especially in its handling of the 
> client_id identifier (when used to obtain end-user authorization). It does 
> not contain any implementation details to accomplish any level of 
> interoperability or functionality. This is in contrast to the assertion grant 
> type which has matured over a year into a fully thought-out extension 
> mechanism, as well as a separate SAML assertion specification with active 
> deployment (the two, together with running code, show clear consensus).
> 2.       The section is a confused mix of security considerations sprinkled 
> with normative language. Instead, it should be replaced with guidelines for 
> extending the set of supported client credentials, but without defining a new 
> registry. It is clearly an area of little deployment experience for OAuth, 
> and that includes using HTTP Basic authentication for client authentication 
> (more on that to come).
> 3.       The section has received a little support and a little objection. 
> Those who still want to advocate for it need to show not only consensus for 
> keeping it, but also active community support for deploying it. Deployment, 
> of course, will also require showing progress on public specifications 
> profiling the mechanism into a useful interoperable feature.
>  
> Comments? Counter-arguments?
>  
> EHL
>  
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to