[Openid-specs-ab] Messages/Standard (was Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)
sakimura at gmail.com
Wed Jul 31 12:32:47 UTC 2013
At the same time, to aid the readership, it may help to come up with a very
concise documentation on the basic cases per flow.
Message tried to be abstract framework, and it got cluttered when it
started to reference OAuth 2.0, which is pretty much HTTP based (though it
is supposedly not.)
There seems to be three branches of complaint:
1. Cannot find which document to start reading / too many documents;
2. Too much features and do not want to read them (e.g., I just want to do
3. Flows are intermingled and difficult to follow;
Given that there are JWT, JWS, JWE, JWK, JWA, RFC6749, RFC6750 outside of
our control, it is kind of difficult to address 1.
However, we could help with 2 and 3.
Basic Client Profile is quite readable. Consider the server version of it.
It would be pretty easy to read.
What I would like to do as an experiment for now is to turn my blog post
into spec format, which explains an absolutely minimum server. That would
at least address 2. and 3. above.
2013/7/31 Brian Campbell <bcampbell at pingidentity.com>
> [switching from OAuth to the Connect list]
> In practice, IMHO, the split between messages and standard doesn't
> actually accomplish anything but to to make the specs larger and harder to
> I get the basic idea/goal of wanting to be decoupled from HTTP but
> Connect, even Messages, is already fully dependent on OAuth, which itself
> "is designed for use with HTTP" . So what does it really accomplish?
> I realize it's probably moot at this point but I felt compelled to mention
> it (again).
>  http://tools.ietf.org/html/rfc6749#section-1
> On Tue, Jul 30, 2013 at 10:43 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>> Right. Anyone who agreed to IPR could have proposed the text in the work
>> Re: Messages and Standard
>> Messages were supposed to be the collection of terminology and parameters
>> Standard was meant to be HTTP binding, which would effectively make it
>> OAuth 2.0 + authentication + identity.
>> As such, normative portion of the standard was to be made of the HTTP
>> protocol element, reference to the parameters sets in Messages, and the
>> documentation on how to serialize. It should be very concise. Non-normative
>> portions were supposed to have examples. In some sections, it is like that,
>> but in sections like 126.96.36.199, it is currently repeating much of what the
>> Messages have.
>> This, to me, is suboptimal but many people wanted to be this way so that
>> they do not have to refer to the Messages.
>> Maybe, for the final, we might reconsider it.
>> 2013/7/31 Richer, Justin P. <jricher at mitre.org>
>> So it's not the protocol that's the problem, it's the documentation.
>>> For that I'm 100% with you all. However, I really don't think that the
>>> right response to that is "we'll just invent something new and incompatible
>>> with slightly different names" -- it's to document the protocol better.
>>> -- Justin
>>> On Jul 30, 2013, at 12:57 PM, Paul Madsen <paul.madsen at gmail.com>
>>> I always think I pretty much understand OIDC until I see the specs list
>>> On 7/30/13 12:39 PM, Brian Campbell wrote:
>>> Yes, that.
>>> On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. <jricher at mitre.org>wrote:
>>>> Yes, I agree that the giant stack of documents is intimidating and in
>>>> my opinion it's a bit of a mess with Messages and Standard split up (but I
>>>> lost that argument years ago).
>>> OAuth mailing listOAuth at ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>> OAuth mailing list
>>> OAuth at ietf.org
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> OAuth mailing list
>> OAuth at ietf.org
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab