[Openid-specs-ab] Breaking change in OAuth 2.0 rev. 23

[John Bradley]

Yes I didn't see any discussion on that before the change.

It is unclear if you can define a new client type,  it is not a real parameter.

Perhaps it is enough to say that any client asking for code token is hybrid and needs to be treated appropriately.  Though that section seems to make having a separate client_id for each component mandatory.




On 2012-03-14, at 7:02 AM, Nat Sakimura wrote:

> I only noticed now that rev 23 had a breaking change. it seems to
> doesn't allow the response_type=code token unless we define another client type such as "hybrid". 
> 
> This is a breaking change. 
> 
> I wonder why I did not notice it till now. 
> 
> See below.
> 
> From section 2.1of
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-v2-23.txt
> 
> "A client application consisting of multiple components, each with its
> own client type (e.g. a distributed client with both a confidential
> server-based component and a public browser-based component), MUST
> register each component separately as a different client to ensure
> proper handling by the authorization server."
> 
> Discuss. 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120314/443523dc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120314/443523dc/attachment.p7s>