[Openid-specs-ab] Messages/Standard (was Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)

Mike Jones Michael.Jones at microsoft.com
Wed Jul 31 13:22:53 UTC 2013


The other complaint that recurs is:

4.  There are too many specifications.

Dick Hardt, Paul Madsen, and others have often stated that they're intimidated by the number of specs.  This will put others off who may not be as friendly to us.

The one case where we could conceivably merge them is Standard and Messages.  Other bindings would then have to just say what they do instead of HTTP messages.  I'm not volunteering to do it, but it would also be an interesting experiment to see what that document would look like.

Something Nat's flowchart in http://nat.sakimura.org/2013/07/28/what-to-read-when-you-want-to-build-openid-connect/ could help, if we could get people to start by reading it.  (I think some edits to it would be needed first.)

I agree that it would be interesting to see the result of Nat's Basic Server doc experiment.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Wednesday, July 31, 2013 5:33 AM
To: Brian Campbell
Cc: <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Messages/Standard (was Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)

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 login) ;
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.

Nat



2013/7/31 Brian Campbell <bcampbell at pingidentity.com<mailto: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 consume.
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" [1]. So what does it really accomplish?

I realize it's probably moot at this point but I felt compelled to mention it (again).

[1] http://tools.ietf.org/html/rfc6749#section-1

On Tue, Jul 30, 2013 at 10:43 PM, Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>> wrote:
Right. Anyone who agreed to IPR could have proposed the text in the work group.

Re: Messages and Standard

Messages were supposed to be the collection of terminology and parameters sets.
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 2.2.1.1, 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<mailto: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<mailto:paul.madsen at gmail.com>>
 wrote:


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<mailto: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 list

OAuth at ietf.org<mailto:OAuth at ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth at ietf.org<mailto:OAuth at ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
OAuth mailing list
OAuth at ietf.org<mailto:OAuth at ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130731/3886918d/attachment-0001.html>


More information about the Openid-specs-ab mailing list