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

Nat Sakimura sakimura at gmail.com
Wed Jul 31 16:48:38 UTC 2013


So, here is my first cut effort of the OpenID Connect Consolidated version.
Having said that, I actually have removed bunch of things from it, like:
- Advanced Claims (Aggregate and Distributed)
- Request Object and Request URL
- Self-Issued Provider
They can be in a separate document, I think.

So, this organization would result in:

- OpenID Connect
- OpenID Connect Discovery
- OpenID Connect Dynamic Registration
- OpenID Connect Advanced Claims Extension
- OpenID Connect Self-Issued Provider Extension
- OpenID Connect JSON Based Request Extension

etc.


2013/7/31 Torsten Lodderstedt <torsten at lodderstedt.net>

> Hi,
>
> I don't think the number of specs itself is the problem but the number of
> specs one has to understand in order to solve a certain problem.
>
> regards,
> Torsten.
>
> Am 31.07.2013 um 15:22 schrieb Mike Jones <Michael.Jones at microsoft.com>:
>
>  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<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>****
>
> [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> 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>****
>
> ** **
>
> 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>****
>
>  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>
> 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****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
> ** **
>
>
> _______________________________________________
> OAuth mailing list
> 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
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> 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
>
>


-- 
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/d603c8e6/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130731/d603c8e6/attachment-0003.html>


More information about the Openid-specs-ab mailing list