[Openid-specs-ab] I'm planning to start applying errata edits to OpenID Connect

Justin Richer jricher at mit.edu
Wed Jul 29 19:00:45 UTC 2015


Where the text started, historically, is irrelevant to how it should be structured, hierarchically, today. If we were building these two specs in parallel right now, then we’d be building the OIDC spec on top of the OAuth spec, just like Core was built on RFC6749/6750. There was discussion about structuring things exactly this way when we started work on the OAuth registration spec, but the IETF took too long (thanks to a few key parties) and this working group rightly moved on and defined it in whole. 

Also note that OIDC also depends very directly on JWT, which wasn’t final at the time either, but the working group decided not to re-define it internally. Much of what went into JWT was originally defined by this working group, too. So the whole notion of “it started here” isn’t relevant to this discussion, or at the very least the argument is being applied very inconsistently.

Is there a compelling reason to not do a new spec, apart from not wanting to write the replacement spec? I understand that the errata process is not for this, and I’m not suggesting that we do that. I’m suggesting we write a new, smaller spec that obsoletes the current one. I think it could be written quickly and simply, with no normative changes.

 — Justin


> On Jul 29, 2015, at 2:35 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> OpenID Connect Dynamic Registration is the original spec.  OAuth Dynamic Registration copied the portions of it that are relevant to generic OAuth, without making any changes.  That’s why you don’t have to try to diff – because there are no salient differences.  You can just use the original spec.
>  
> Yes, the OAuth spec adds some optional things, such as software_version and software_statement, but implementations don’t need to use them.  If a profile, such as MODRNA does use them, it should refer to them in RFC 7591 directly.
>  
> We’ll be clear about these things in the spec itself, so developers won’t have to guess whether there are differences or refer back to this thread to have this information.
>  
>                                                             Best wishes,
>                                                             -- Mike
>  
> From: Vivek Biswas [mailto:vivek.biswas at gmail.com] 
> Sent: Wednesday, July 29, 2015 11:13 AM
> To: Mike Jones
> Cc: Justin Richer; William Denniss; openid-specs-ab at lists.openid.net Ab
> Subject: Re: [Openid-specs-ab] I'm planning to start applying errata edits to OpenID Connect
>  
> To be very honest as a developer, I find it quite confusing to read 1 concise spec and than trying to diff between the profile of the spec and the original spec.
>  It makes lot easier to know exactly what has changed in the profile of the spec vs the original spec and implement only the piece that has changed.
> 
> -Vivek
>  
> On Wed, Jul 29, 2015 at 10:54 AM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
> Actually, implementers don’t have to read two specs.  They only have to read the Connect registration spec.  It’s complete.
>  
> From: Justin Richer [mailto:jricher at mit.edu <mailto:jricher at mit.edu>] 
> Sent: Wednesday, July 29, 2015 10:46 AM
> To: William Denniss
> 
> Cc: Mike Jones; openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net> Ab
> Subject: Re: [Openid-specs-ab] I'm planning to start applying errata edits to OpenID Connect
>  
> +1 to this — the Core spec doesn’t redefine how to do OAuth, but includes it by reference and example. We can do the same here.
>  
>  — Justin
>  
> On Jul 29, 2015, at 1:44 PM, William Denniss <wdenniss at google.com <mailto:wdenniss at google.com>> wrote:
>  
> If there is duplication, implementors will need to read two specs, and manually diff them.  Personally I dislike doing that, and prefer 1 clear authoritative reference.
>  
> Given we have clear definition of the layers, in that Connect runs on OAuth, I think it makes sense for the specs to be structured in that way too.
>  
> For example, I think that the Connect Core doc would be a lot more confusing if it subsumed the entire OAuth spec.  It's better to say "you already know (and might have implemented) OAuth, here are the extra bits you need for Connect".
>  
> On Wed, Jul 29, 2015 at 10:38 AM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
> I actually disagree that this makes things easier for implementers.  Right now OpenID registration is self-contained.  People implementing it only need to refer to one spec.  If we remove the duplication, people will have to keep going back and forth between two specs.  Developers hate that.
>  
>                                                             -- Mike
>  
> From: William Denniss [mailto:wdenniss at google.com <mailto:wdenniss at google.com>] 
> Sent: Wednesday, July 29, 2015 10:35 AM
> To: Justin Richer
> Cc: Mike Jones; openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net> Ab
> 
> Subject: Re: [Openid-specs-ab] I'm planning to start applying errata edits to OpenID Connect
>  
>  
> +1
>  
> A revision that removes the duplication would help implementers. It's good to cleanly separate the OAuth and Connect layers, now that we can.
>  
> On Wed, Jul 29, 2015 at 10:10 AM, Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>> wrote:
> I can understand the rationale of not doing this during an errata action, but now that the IETF specs are available, what would it take for the WG to actually update the documents as Torsten suggests? The OIDC registration draft could really be quite minimal and import RFC7592 and RFC7592 directly for most of its normative content. The OIDC draft only adds a few fields to the client model and values to some fields (like response_type and token_endpoint_auth_method), but overall it isn’t any different.
>  
> I think it’s very unfortunate that the OAuth WG sat on this work for so long, otherwise we could have had it set up this way from the beginning. 
>  
>  — Justin
>  
> On Jul 29, 2015, at 12:37 PM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>  
> We’re not going to do major changes as part of an errata action, so we’re not going to remove the now-duplicated content.  That said, we will add a statement that the OpenID Registration spec is compatible with the OAuth Registration spec and that implementations are free to use features defined there such as software statements as appropriate.  Would that work for you?
>  
>                                                             -- Mike
>  
> From: torsten at lodderstedt.net <mailto:torsten at lodderstedt.net> [mailto:torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>]
> Sent: Wednesday, July 29, 2015 5:05 AM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>
> Subject: Re: [Openid-specs-ab] I'm planning to start applying errata edits to OpenID Connect
>  
> Hi Mike,
> good to hear.
> Regarding Dynamic Client Registration: Will you modify the OpenID Connect Spec to be based on RFC 7591? I'm asking because the OIDC Client Registration could be strip down (e.g. by removing the definition of registration request/response). Moreover, this would allow the OIDC version to leverage software statements, which are required for the MODRNA work.
> best regards,
> Torsten.
> Am 24.07.2015 20:14, schrieb Mike Jones:
> I wanted to let you know that I plan to start applying errata edits to the OpenID Connect specifications.  These edits will include:
> ·        Referencing the JOSE, JWT, OAuth Assertions, and acct URI RFCs instead of working group drafts
> ·        Registering the Connect-specific Dynamic Registration metadata values in the registry established by RFC 7591
> ·        Removing the warning about the Google “iss” value currently in Section 15.6.2
> ·        Addressing typos described in the issue tracker
>  
> If you know of other issues that we need to address as errata, please add them to the issue tracker athttps://bitbucket.org/openid/connect/issues?status=new&status=open <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbitbucket.org%2fopenid%2fconnect%2fissues%3fstatus%3dnew%26status%3dopen&data=01%7c01%7cMichael.Jones%40microsoft.com%7c31bcba812779461de4dc08d2980df30d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HXg%2bwHa8bJiF7SLAJUyFK0Lwp6SBXdWE27KLYYiXmHM%3d> using the milestone “Errata”.
>  
> Note that I’ll first publish the updated drafts tohttp://openid.bitbucket.org/ <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.bitbucket.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c31bcba812779461de4dc08d2980df30d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vcv4rTg9svF8fZYynqgEF7oV3N%2bEt2oVn0Tu%2bcrkJa8%3d> for review.  Also, I think we should wait until draft-ietf-jose-jwk-thumbprint <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jwk-thumbprint-08&data=01%7c01%7cMichael.Jones%40microsoft.com%7c31bcba812779461de4dc08d2980df30d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Abm%2brWGKRUjm0nf0zVUsAIdo%2b47JvLs54T2WDVPat%2fY%3d> exits the RFC Editor queue and becomes an RFC before we call this second errata round done.
>  
>                                                             -- Mike
>  
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7c31bcba812779461de4dc08d2980df30d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TCG5eGRf7Z73v3O1CdCcVLBp6kXmee66VK2fV9iAD8w%3d>
>  
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7cc0ed08410e1a4039ce0d08d2983c233c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IaRnzhdrFCvaWRyxa5YE9YR%2bVvGmC8%2btLpNs%2fEVzC%2f8%3d>
>  
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7cc0ed08410e1a4039ce0d08d2983c233c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IaRnzhdrFCvaWRyxa5YE9YR%2bVvGmC8%2btLpNs%2fEVzC%2f8%3d>
>  
>  
>  
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf4c6609f867b4c2bac6508d298414e39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=r9PZEM6ysL2H4ePQvCvv2caXfxmGmWkNMuWq6ew9J4E%3d>
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150729/6b9c9c7e/attachment-0001.html>


More information about the Openid-specs-ab mailing list