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

[Nat Sakimura]

On 2012/03/14, at 7:27, John Bradley <ve7jtb at ve7jtb.com> wrote:

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.


Indeed, and that's the breaking point.






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/cefe6129/attachment.html>