Subject: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Jul 2014 13:54:22 +0200

Hi Phil, John, Maciej, Justin, Mike,

I am working on the shepherd writeup for the dynamic client registration
document and one item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Ciao
Hannes

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Jul 2014 09:11:19 -0700

I confirm I have no IPR disclosures on this document. 

Phil

> On Jul 8, 2014, at 4:54, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Jul 2014 17:06:12 +0000

I likewise do not hold any IPR on these specs.
________________________________
From: Phil Hunt<mailto:[email-masked]>
Sent: ‎7/‎8/‎2014 9:11 AM
To: Hannes Tschofenig<mailto:[email-masked]>
Cc: Mike Jones<mailto:[email-masked]>; John Bradley<mailto:[email-masked]>; Justin Richer<mailto:[email-masked]>; Maciej Machulak<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Dynamic Client Registration: IPR Confirmation

Phil

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 Jul 2014 02:14:46 +0000

Thinking about this some more, there is one IPR issue that we need to address before publication.  This specification is a derivative work from the OpenID Connect Dynamic Registration specification http://openid.net/specs/openid-connect-registration-1_0.html.  Large portions of the text were copied wholesale from that spec to this one, so that the two would be compatible.  (This is good thing – not a bad thing.)

This is easy to address from an IPR perspective – simply acknowledge that this spec is a derivative work and provide proper attribution.  The OpenID copyright in the spec at http://openid.net/specs/openid-connect-registration-1_0.html#Notices allows for this resolution.  It says:

Copyright (c) 2014 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
Let’s add the reference and acknowledgment in the next version.

                                                            -- Mike

From: Mike Jones
Sent: Tuesday, July 08, 2014 10:06 AM
To: Phil Hunt; Hannes Tschofenig
Cc: John Bradley; Justin Richer; Maciej Machulak; [email-masked]
Subject: RE: Dynamic Client Registration: IPR Confirmation

Phil

> On Jul 8, 2014, at 4:54, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Tue, 8 Jul 2014 22:20:14 -0400

Yes Nat and I mentioned the need for attribution to Hannes. 

Having that also helps clarify the relationship between the specs for readers. 

Sent from my iPhone

> On Jul 8, 2014, at 10:14 PM, Mike Jones <[email-masked]> wrote:
> 
> From: Phil Hunt
> To: Hannes Tschofenig
> Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machulak; [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Tue, 15 Jul 2014 19:46:46 +0000

So that the working group has concrete language to consider, propose the following language to the OAuth Dynamic Client Registration specification:

Portions of this specification are derived from the OpenID Connect Dynamic Registration [OpenID.Registration] specification.  This was done so that implementations of this specification and OpenID Connect Dynamic Registration can be compatible with one another.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, July 08, 2014 7:15 PM
To: Phil Hunt; Hannes Tschofenig
Cc: Maciej Machulak; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

                                                            -- Mike

From: Mike Jones
Sent: Tuesday, July 08, 2014 10:06 AM
To: Phil Hunt; Hannes Tschofenig
Cc: John Bradley; Justin Richer; Maciej Machulak; [email-masked]<mailto:[email-masked]>
Subject: RE: Dynamic Client Registration: IPR Confirmation

Phil

---

From: Maciej Machulak <[email-masked]>
Date: Wed, 16 Jul 2014 11:03:46 +0200

Hi,

My apologies for a late reply. Same here, no IPR disclosures to make
regarding these documents.

Kind regards,
Maciej

On 8 July 2014 19:06, Mike Jones <[email-masked]> wrote:

>   ------------------------------
> From: Phil Hunt <[email-masked]>
> To: Hannes Tschofenig <[email-masked]>
> Cc: Mike Jones <[email-masked]>; John Bradley
> <[email-masked]>; Justin Richer <[email-masked]>; Maciej Machulak
> <[email-masked]>; [email-masked]
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Maciej Machulak
email: [email-masked]
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2014 12:17:04 +0200

Thanks, Mike.

This is a useful addition and reflects the relationship between the two
efforts.

Please add it to the next draft version.

Ciao
Hannes

On 07/15/2014 09:46 PM, Mike Jones wrote:
> So that the working group has concrete language to consider, propose the
> following language to the OAuth Dynamic Client Registration specification:
> 
>  
> 
> Portions of this specification are derived from the OpenID Connect
> Dynamic Registration [OpenID.Registration] specification.  This was done
> so that implementations of this specification and OpenID Connect Dynamic
> Registration can be compatible with one another.
> 
>  
> 
>                                                             -- Mike
> 
>  
> 
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *Sent:* Tuesday, July 08, 2014 7:15 PM
> *To:* Phil Hunt; Hannes Tschofenig
> *Cc:* Maciej Machulak; [email-masked]
> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
> 
>  
> 
> Thinking about this some more, there is one IPR issue that we need to
> address before publication.  This specification is a derivative work
> from the OpenID Connect Dynamic Registration specification
> http://openid.net/specs/openid-connect-registration-1_0.html.  Large
> portions of the text were copied wholesale from that spec to this one,
> so that the two would be compatible.  (This is good thing – not a bad
> thing.)
> 
>  
> 
> This is easy to address from an IPR perspective – simply acknowledge
> that this spec is a derivative work and provide proper attribution.  The
> OpenID copyright in the spec at
> http://openid.net/specs/openid-connect-registration-1_0.html#Notices
> allows for this resolution.  It says:
> 
>  
> 
> The OpenID Foundation (OIDF) grants to any Contributor, developer,
> implementer, or other interested party a non-exclusive, royalty free,
> worldwide copyright license to reproduce, prepare derivative works from,
> distribute, perform and display, this Implementers Draft or Final
> Specification solely for the purposes of (i) developing specifications,
> and (ii) implementing Implementers Drafts and Final Specifications based
> on such documents, provided that attribution be made to the OIDF as the
> source of the material, but that such attribution does not indicate an
> endorsement by the OIDF.
> 
> *From:*Mike Jones
> *Sent:* Tuesday, July 08, 2014 10:06 AM
> *To:* Phil Hunt; Hannes Tschofenig
> *Cc:* John Bradley; Justin Richer; Maciej Machulak; [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From: *Phil Hunt <mailto:[email-masked]>
> *Sent: *‎7/‎8/‎2014 9:11 AM
> *To: *Hannes Tschofenig <mailto:[email-masked]>
> *Cc: *Mike Jones <mailto:[email-masked]>; John Bradley
> <mailto:[email-masked]>; Justin Richer <mailto:[email-masked]>;
> Maciej Machulak <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
> 
>> On Jul 8, 2014, at 4:54, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Jul 2014 07:41:16 -0400

I thought I had sent this note already, but I don't see it in the 
archives or in my 'sent' folder:

If we're going to point to OpenID Connect (which I'm fine with), then we 
should clarify that portions were also taken from the UMA specification. 
In fact, draft -00 actually *was* the UMA specification text entirely. 
This is also what the OpenID Connect registration specification was 
(loosely) based on when it was started.

In reality, the relationship between these three documents from three 
different SBO's is more complicated: they all grew up together and 
effectively merged to become wire-compatible with each other. There were 
a number of changes that were discussed here in the IETF that OpenID 
Connect adopted, and a number of changes that were discussed at OIDF 
that were adopted here. OIDC also extends the IETF draft with a set of 
OIDC-specific metadata fields and editorial language that makes it fit 
more closely in the OIDC landscape, but make no mistake: they're the 
same protocol. In the case of UMA, it's a straight normative reference 
to the IETF document now because we were able to incorporate those use 
cases and parameters directly.

The trouble is, I'm not sure how to concisely state that all that in the 
draft text, but it's not as simple as "we copied OpenID", which is what 
the text below seems to say.

  -- Justin

On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
>> so that the two would be compatible.  (This is good thing -- not a bad
>> thing.)
>>
>>   
>>
>> This is easy to address from an IPR perspective -- simply acknowledge
>> Let's add the reference and acknowledgment in the next version.
>>
>>   
>>
>>                                                              -- Mike
>>
>>   
>>
>> *From:*Mike Jones
>> *Sent: *?7/?8/?2014 9:11 AM

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2014 13:44:48 +0200

Interesting background information. Maybe we should then extend the note
Mike provided to also clarify the relationship with the UMA work (both
in terms to IPR, copyright, and attribution-wise).

It would also make sense to state the relationship in the introduction
to highlight the compatibility, which I believe is a big accomplishment.

Ciao
Hannes

---

From: Maciej Machulak <[email-masked]>
Date: Wed, 16 Jul 2014 13:51:17 +0200

Hi,

Yes, I agree - I think the note should mention UMA. As Justin proposed,
there should be a normative reference to an IETF document.

Kind regards,
Maciej

> >>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>> wrote:
> >>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Jul 2014 07:52:55 -0400

I like the idea of adding some of the text in the introduction, as I 
agree the compatibility is an important (and hard-won) accomplishment. I 
think taking Mike's text, expanding it, and putting it in the 
introduction might serve the overall purpose just fine:

Portions of this specification are derived from the OpenID Connect
Dynamic Registration [OpenID.Registration] specification and from
the User Managed Access [UMA] specification.  This was done
so that implementations of these three specifications will be
compatible with one another.

These are both informative references, so we can reference the ID for UMA.

  -- Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 16 Jul 2014 12:34:49 +0000

I disagree with one aspect of Justin's characterization of the history of the spec and have data to back up my disagreement.  The OpenID Connect Dynamic Registration Specification was not based on draft-ietf-oauth-dyn-reg-00 or the UMA specification.  It was created independently by John Bradley in June 2011 based upon OpenID Connect working group discussions that predated draft-ietf-oauth-dyn-reg-00, and for which there are working group notes documenting the OpenID Connect working group decisions prior to the IETF -00 draft.  Yes, there's plenty of evidence that the IETF -01 draft copied text from the early OpenID Connect draft (including in the change history), but the Connect authors were careful to follow the OpenID Foundation's IPR process and not incorporate contributions from third parties who hadn't signed an OpenID IPR Contribution Agreement stating that the OpenID Foundation was free to use their contributions.  (This fills the same role as the IETF Note well, but with a signed agreement, and ensures that all developers can use the resulting specifications without IPR concerns based on IPR that may be held by the contributors.)  The OpenID Connect Dynamic Registration draft didn't copy from the UMA draft or the IETF draft derived from it, so as to maintain the IPR integrity of the OpenID document.  The copying all went in the other direction.

If portions of the UMA draft remained from -00 in the current drafts, I'd be fine with the UMA attribution, but in practice they don't.  The UMA content was replaced with the OpenID Connect content.  (I believe that eventually UMA decided to drop their old draft and move to registration mechanisms that were compatible with Connect as well, and stopped using their previous registration data formats.)

				-- Mike

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2014 4:53 AM
To: Hannes Tschofenig; Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

I like the idea of adding some of the text in the introduction, as I agree the compatibility is an important (and hard-won) accomplishment. I think taking Mike's text, expanding it, and putting it in the introduction might serve the overall purpose just fine:

Portions of this specification are derived from the OpenID Connect Dynamic Registration [OpenID.Registration] specification and from the User Managed Access [UMA] specification.  This was done so that implementations of these three specifications will be compatible with one another.

  -- Justin

On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:
> Interesting background information. Maybe we should then extend the 
> note Mike provided to also clarify the relationship with the UMA work 
> (both in terms to IPR, copyright, and attribution-wise).
>
>> If we're going to point to OpenID Connect (which I'm fine with), then 
>> we should clarify that portions were also taken from the UMA specification.
>> effectively merged to become wire-compatible with each other. There 
>> were a number of changes that were discussed here in the IETF that 
>> OpenID Connect adopted, and a number of changes that were discussed 
>> at OIDF that were adopted here. OIDC also extends the IETF draft with 
>> a set of OIDC-specific metadata fields and editorial language that 
>> makes it fit more closely in the OIDC landscape, but make no mistake: 
>> they're the same protocol. In the case of UMA, it's a straight 
>> normative reference to the IETF document now because we were able to 
>> incorporate those use cases and parameters directly.
>>
>> The trouble is, I'm not sure how to concisely state that all that in 
>> the draft text, but it's not as simple as "we copied OpenID", which 
>> is what the text below seems to say.
>>
>>   -- Justin
>>
>>> This is a useful addition and reflects the relationship between the 
>>> two efforts.
>>>
>>>> So that the working group has concrete language to consider, 
>>>> propose the following language to the OAuth Dynamic Client Registration specification:
>>>>
>>>>   
>>>>
>>>> Dynamic Registration [OpenID.Registration] specification.  This was 
>>>> done so that implementations of this specification and OpenID 
>>>> Connect Dynamic Registration can be compatible with one another.
>>>>
>>>>   
>>>>
>>>>                                                              -- 
>>>> Mike
>>>>
>>>>   
>>>>
>>>> Thinking about this some more, there is one IPR issue that we need 
>>>> to address before publication.  This specification is a derivative 
>>>> work from the OpenID Connect Dynamic Registration specification 
>>>> http://openid.net/specs/openid-connect-registration-1_0.html.  
>>>> Large portions of the text were copied wholesale from that spec to 
>>>> this one, so that the two would be compatible.  (This is good thing 
>>>> – not a bad
>>>> thing.)
>>>>
>>>>   
>>>>
>>>> This is easy to address from an IPR perspective – simply 
>>>> acknowledge that this spec is a derivative work and provide proper 
>>>> attribution.  The OpenID copyright in the spec at 
>>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notice
>>>> s allows for this resolution.  It says:
>>>>
>>>>   
>>>>
>>>> implementer, or other interested party a non-exclusive, royalty 
>>>> free, worldwide copyright license to reproduce, prepare derivative 
>>>> works from, distribute, perform and display, this Implementers 
>>>> Draft or Final Specification solely for the purposes of (i) 
>>>> developing specifications, and (ii) implementing Implementers 
>>>> Drafts and Final Specifications based on such documents, provided 
>>>> that attribution be made to the OIDF as the source of the material, 
>>>> but that such attribution does not indicate an endorsement by the OIDF.
>>>>
>>>> Mike
>>>> <mailto:[email-masked]>; Justin Richer 
>>>> <mailto:[email-masked]>; Maciej Machulak 
>>>> <mailto:[email-masked]>; [email-masked] 
>>>> <mailto:[email-masked]>
>>>>> I am working on the shepherd writeup for the dynamic client 
>>>>> registration document and one item in the template requires me to 
>>>>> indicate whether each document author has confirmed that any and 
>>>>> all appropriate IPR disclosures required for full conformance with 
>>>>> the provisions of BCP 78 and BCP 79 have already been filed.
>>>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Jul 2014 08:54:09 -0400

It's quite true that the OIDC draft predates -00 of the IETF draft, and 
I'm sorry if that was unclear from what I said as I was not intending to 
misrepresent the history. And it's true that the UMA draft predates both 
of these by a fair whack and at the very least provided inspiration in 
how to accomplish this task, and in fact draft -00 was a straight copy 
of UMA. As Mike mentions below, draft -01 (when I took over the editor 
role) incorporates a lot of text from the OIDF draft alongside the UMA 
text, which is why that document has eight authors on it.

However it's not true that information didn't flow both ways, or that 
everything from UMA was eventually expunged. It's fairly clear if you 
look at the document history that there was a lot of back and forth. The 
JSON formatting in the IETF draft, for example, exists in -00 and came 
from UMA, was switched to form encoding from in -01 (from OIDC), and 
with lots of discussion here in the WG (both before and after the 
change) was switched back to JSON in -05. At that time, there was a 
discussion in the OIDF working group of whether to adopt the JSON 
formatting as well in order to maintain compatibility, and OIDF decided 
to do so. There were other instances where parameter names and other 
ideas began in the IETF and moved to OIDF's spec, like changing 
"issued_at" to the more clear "client_id_issued_at". These were breaking 
changes and not entered into lightly, and I was there for those 
discussions and still contend that OIDF made the right call.

If the OIDF wants to frame that decision as "we decided independently to 
do a thing for the greater good" as opposed to "we adopted ideas from 
outside", then it's free to do so for whatever legal protection reasons 
it likes. It's perfectly fine with me that the OIDF represent itself and 
its documents how it sees best. But it's not OK with me to discount or 
misrepresent the history and provenance of the ideas and components of 
this IETF document in the IETF and I'd like to include the modified 
statement I posted below in the introduction text of the next revision.

  -- Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 16 Jul 2014 13:54:12 +0000

OK - looking back at the parameter name change example, I agree that this was first discussed in the OAuth WG and was adopted by both specs at about the same time, so I agree that that's an example of information flowing in the other direction.  (I doubt that anyone will assert IPR about a parameter name change, so I suspect that instance was innocuous.)  When some of the same people were in two working groups doing highly related things, I suppose some of that was bound to happen, despite the best of intentions.  However, it's still my assertion that the core inventions in Connect Registration were independently developed, syntax tweaks made later for compatibility reasons aside.

Be that as it may, and having thought about it some more, I'm not going to stand in the way of acknowledging UMA in the OAuth Registration spec if people believe that that's the right thing to do.  People who know me know that I'm all in favor of giving credit where credit is due.  I'd thought that all the UMA content had been replaced, but if I'm wrong about that, so be it.

What would be the right reference for the UMA registration specification in the acknowledgement?

				-- Mike

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2014 5:54 AM
To: Mike Jones; Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

It's quite true that the OIDC draft predates -00 of the IETF draft, and I'm sorry if that was unclear from what I said as I was not intending to misrepresent the history. And it's true that the UMA draft predates both of these by a fair whack and at the very least provided inspiration in how to accomplish this task, and in fact draft -00 was a straight copy of UMA. As Mike mentions below, draft -01 (when I took over the editor
role) incorporates a lot of text from the OIDF draft alongside the UMA text, which is why that document has eight authors on it.

However it's not true that information didn't flow both ways, or that everything from UMA was eventually expunged. It's fairly clear if you look at the document history that there was a lot of back and forth. The JSON formatting in the IETF draft, for example, exists in -00 and came from UMA, was switched to form encoding from in -01 (from OIDC), and with lots of discussion here in the WG (both before and after the
change) was switched back to JSON in -05. At that time, there was a discussion in the OIDF working group of whether to adopt the JSON formatting as well in order to maintain compatibility, and OIDF decided to do so. There were other instances where parameter names and other ideas began in the IETF and moved to OIDF's spec, like changing "issued_at" to the more clear "client_id_issued_at". These were breaking changes and not entered into lightly, and I was there for those discussions and still contend that OIDF made the right call.

If the OIDF wants to frame that decision as "we decided independently to do a thing for the greater good" as opposed to "we adopted ideas from outside", then it's free to do so for whatever legal protection reasons it likes. It's perfectly fine with me that the OIDF represent itself and its documents how it sees best. But it's not OK with me to discount or misrepresent the history and provenance of the ideas and components of this IETF document in the IETF and I'd like to include the modified statement I posted below in the introduction text of the next revision.

  -- Justin

On 7/16/2014 8:34 AM, Mike Jones wrote:
> If portions of the UMA draft remained from -00 in the current drafts, 
> I'd be fine with the UMA attribution, but in practice they don't.  The 
> UMA content was replaced with the OpenID Connect content.  (I believe 
> that eventually UMA decided to drop their old draft and move to 
> registration mechanisms that were compatible with Connect as well, and 
> stopped using their previous registration data formats.)
>
> 				-- Mike
>
>> It would also make sense to state the relationship in the 
>> introduction to highlight the compatibility, which I believe is a big accomplishment.
>>
>> Ciao
>> Hannes
>>
>>> If we're going to point to OpenID Connect (which I'm fine with), 
>>> then we should clarify that portions were also taken from the UMA specification.
>>> In reality, the relationship between these three documents from 
>>> three different SBO's is more complicated: they all grew up together 
>>> and effectively merged to become wire-compatible with each other. 
>>> There were a number of changes that were discussed here in the IETF 
>>> that OpenID Connect adopted, and a number of changes that were 
>>> discussed at OIDF that were adopted here. OIDC also extends the IETF 
>>> draft with a set of OIDC-specific metadata fields and editorial 
>>> language that makes it fit more closely in the OIDC landscape, but make no mistake:
>>>>> Dynamic Registration [OpenID.Registration] specification.  This 
>>>>> was done so that implementations of this specification and OpenID 
>>>>> this one, so that the two would be compatible.  (This is good 
>>>>> thing – not a bad
>>>>> thing.)
>>>>>
>>>>>    
>>>>>
>>>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notic
>>>>> e s allows for this resolution.  It says:
>>>>>
>>>>>    
>>>>>
>>>>> that attribution be made to the OIDF as the source of the 
>>>>> material, but that such attribution does not indicate an endorsement by the OIDF.
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -----
>>>>>
>>>>> *Cc: *Mike Jones <mailto:[email-masked]>; John 
>>>>> Bradley <mailto:[email-masked]>; Justin Richer 
>>>>>> all appropriate IPR disclosures required for full conformance 
>>>>>> with the provisions of BCP 78 and BCP 79 have already been filed.
>>>>>>

---

From: Maciej Machulak <[email-masked]>
Date: Wed, 16 Jul 2014 16:12:31 +0200

Mike,

See comments below:

On 16 July 2014 15:54, Mike Jones <[email-masked]> wrote:

> OK - looking back at the parameter name change example, I agree that this
> was first discussed in the OAuth WG and was adopted by both specs at about
> the same time, so I agree that that's an example of information flowing in
> the other direction.  (I doubt that anyone will assert IPR about a
> parameter name change, so I suspect that instance was innocuous.)  When
> some of the same people were in two working groups doing highly related
> things, I suppose some of that was bound to happen, despite the best of
> intentions.  However, it's still my assertion that the core inventions in
> Connect Registration were independently developed, syntax tweaks made later
> for compatibility reasons aside.
>
> Be that as it may, and having thought about it some more, I'm not going to
> stand in the way of acknowledging UMA in the OAuth Registration spec if
> people believe that that's the right thing to do.  People who know me know
> that I'm all in favor of giving credit where credit is due.  I'd thought
> that all the UMA content had been replaced, but if I'm wrong about that, so
> be it.
>

That is fine - if the content has been removed then just don't give the
credit - I'm fine both ways.

> What would be the right reference for the UMA registration specification

This is the latest doc that was ever produced, as far as I am aware of:
http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03

Kind regards,
Maciej

> misrepresent the history. And it's true that the UMA draft predates both of
> these by a fair whack and at the very least provided inspiration in how to
> accomplish this task, and in fact draft -00 was a straight copy of UMA. As
> Mike mentions below, draft -01 (when I took over the editor
> everything from UMA was eventually expunged. It's fairly clear if you look
> at the document history that there was a lot of back and forth. The JSON
> formatting in the IETF draft, for example, exists in -00 and came from UMA,
> was switched to form encoding from in -01 (from OIDC), and with lots of
> discussion here in the WG (both before and after the
> formatting as well in order to maintain compatibility, and OIDF decided to
> do so. There were other instances where parameter names and other ideas
> began in the IETF and moved to OIDF's spec, like changing "issued_at" to
> the more clear "client_id_issued_at". These were breaking changes and not
> entered into lightly, and I was there for those discussions and still
> contend that OIDF made the right call.
>
> outside", then it's free to do so for whatever legal protection reasons it
> likes. It's perfectly fine with me that the OIDF represent itself and its
> documents how it sees best. But it's not OK with me to discount or
> misrepresent the history and provenance of the ideas and components of this
> IETF document in the IETF and I'd like to include the modified statement I
> posted below in the introduction text of the next revision.
>
>   -- Justin
>
> > I disagree with one aspect of Justin's characterization of the history
> of the spec and have data to back up my disagreement.  The OpenID Connect
> Dynamic Registration Specification was not based on
> draft-ietf-oauth-dyn-reg-00 or the UMA specification.  It was created
> independently by John Bradley in June 2011 based upon OpenID Connect
> working group discussions that predated draft-ietf-oauth-dyn-reg-00, and
> for which there are working group notes documenting the OpenID Connect
> working group decisions prior to the IETF -00 draft.  Yes, there's plenty
> of evidence that the IETF -01 draft copied text from the early OpenID
> Connect draft (including in the change history), but the Connect authors
> were careful to follow the OpenID Foundation's IPR process and not
> incorporate contributions from third parties who hadn't signed an OpenID
> IPR Contribution Agreement stating that the OpenID Foundation was free to
> use their contributions.  (This fills the same role as the IETF Note well,
> but with a signed agreement, and ensures that all developers can use the
> resulting specifications without IPR concerns based on IPR that may be held
> by the contributors.)  The OpenID Connect Dynamic Registration draft didn't
> copy from the UMA draft or the IETF draft derived from it, so as to
> maintain the IPR integrity of the OpenID document.  The copying all went in
> the other direction.
> >
> think taking Mike's text, expanding it, and putting it in the introduction
> might serve the overall purpose just fine:
> >
> Dynamic Registration [OpenID.Registration] specification and from the User
> Managed Access [UMA] specification.  This was done so that implementations
> of these three specifications will be compatible with one another.
> >
> >
> >>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig <
> [email-masked] <mailto:[email-masked]>> wrote:
> >>>>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Jul 2014 11:44:38 -0400

Since it's an information reference, I would like to reference the 
as-of-now-current ID for UMA:

http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09

  -- Justin

On 07/16/2014 10:12 AM, Maciej Machulak wrote:
> Mike,
>
> See comments below:
>
> On 16 July 2014 15:54, Mike Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     OK - looking back at the parameter name change example, I agree
>     that this was first discussed in the OAuth WG and was adopted by
>     both specs at about the same time, so I agree that that's an
>     example of information flowing in the other direction.  (I doubt
>     that anyone will assert IPR about a parameter name change, so I
>     suspect that instance was innocuous.)  When some of the same
>     people were in two working groups doing highly related things, I
>     suppose some of that was bound to happen, despite the best of
>     intentions.  However, it's still my assertion that the core
>     inventions in Connect Registration were independently developed,
>     syntax tweaks made later for compatibility reasons aside.
>
>     Be that as it may, and having thought about it some more, I'm not
>     going to stand in the way of acknowledging UMA in the OAuth
>     Registration spec if people believe that that's the right thing to
>     do.  People who know me know that I'm all in favor of giving
>     credit where credit is due.  I'd thought that all the UMA content
>     had been replaced, but if I'm wrong about that, so be it.
>
>
> That is fine - if the content has been removed then just don't give 
> the credit - I'm fine both ways.
>
>
>     From: Justin Richer [mailto:[email-masked] <mailto:[email-masked]>]
>     It's quite true that the OIDC draft predates -00 of the IETF
>     draft, and I'm sorry if that was unclear from what I said as I was
>     not intending to misrepresent the history. And it's true that the
>     UMA draft predates both of these by a fair whack and at the very
>     least provided inspiration in how to accomplish this task, and in
>     fact draft -00 was a straight copy of UMA. As Mike mentions below,
>     draft -01 (when I took over the editor
>     role) incorporates a lot of text from the OIDF draft alongside the
>     UMA text, which is why that document has eight authors on it.
>
>     However it's not true that information didn't flow both ways, or
>     that everything from UMA was eventually expunged. It's fairly
>     clear if you look at the document history that there was a lot of
>     back and forth. The JSON formatting in the IETF draft, for
>     example, exists in -00 and came from UMA, was switched to form
>     encoding from in -01 (from OIDC), and with lots of discussion here
>     in the WG (both before and after the
>     change) was switched back to JSON in -05. At that time, there was
>     a discussion in the OIDF working group of whether to adopt the
>     JSON formatting as well in order to maintain compatibility, and
>     OIDF decided to do so. There were other instances where parameter
>     names and other ideas began in the IETF and moved to OIDF's spec,
>     like changing "issued_at" to the more clear "client_id_issued_at".
>     These were breaking changes and not entered into lightly, and I
>     was there for those discussions and still contend that OIDF made
>     the right call.
>
>     If the OIDF wants to frame that decision as "we decided
>     independently to do a thing for the greater good" as opposed to
>     "we adopted ideas from outside", then it's free to do so for
>     whatever legal protection reasons it likes. It's perfectly fine
>     with me that the OIDF represent itself and its documents how it
>     sees best. But it's not OK with me to discount or misrepresent the
>     history and provenance of the ideas and components of this IETF
>     document in the IETF and I'd like to include the modified
>     > I disagree with one aspect of Justin's characterization of the
>     history of the spec and have data to back up my disagreement.  The
>     OpenID Connect Dynamic Registration Specification was not based on
>     draft-ietf-oauth-dyn-reg-00 or the UMA specification.  It was
>     created independently by John Bradley in June 2011 based upon
>     OpenID Connect working group discussions that predated
>     draft-ietf-oauth-dyn-reg-00, and for which there are working group
>     notes documenting the OpenID Connect working group decisions prior
>     to the IETF -00 draft.  Yes, there's plenty of evidence that the
>     IETF -01 draft copied text from the early OpenID Connect draft
>     (including in the change history), but the Connect authors were
>     careful to follow the OpenID Foundation's IPR process and not
>     incorporate contributions from third parties who hadn't signed an
>     OpenID IPR Contribution Agreement stating that the OpenID
>     Foundation was free to use their contributions.  (This fills the
>     same role as the IETF Note well, but with a signed agreement, and
>     ensures that all developers can use the resulting specifications
>     without IPR concerns based on IPR that may be held by the
>     contributors.)  The OpenID Connect Dynamic Registration draft
>     didn't copy from the UMA draft or the IETF draft derived from it,
>     so as to maintain the IPR integrity of the OpenID document.  The
>     copying all went in the other direction.
>     >
>     > From: Justin Richer [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > I like the idea of adding some of the text in the introduction,
>     as I agree the compatibility is an important (and hard-won)
>     accomplishment. I think taking Mike's text, expanding it, and
>     putting it in the introduction might serve the overall purpose
>     just fine:
>     >
>     > Portions of this specification are derived from the OpenID
>     Connect Dynamic Registration [OpenID.Registration] specification
>     and from the User Managed Access [UMA] specification.  This was
>     done so that implementations of these three specifications will be
>     >>>>> *From:*OAuth [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Mike
>     >>>>> Jones
>     >>>>> *Cc:* Maciej Machulak; [email-masked] <mailto:[email-masked]>
>     >>>>> thing -- not a bad
>     >>>>> This is easy to address from an IPR perspective -- simply
>     >>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak;
>     [email-masked] <mailto:[email-masked]>
>     >>>>> <mailto:[email-masked] <mailto:[email-masked]>>
>     >>>>> *From: *Phil Hunt <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>>>> *To: *Hannes Tschofenig <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>>>> *Cc: *Mike Jones <mailto:[email-masked]
>     <mailto:[email-masked]>>; John
>     >>>>> Bradley <mailto:[email-masked]
>     <mailto:[email-masked]>>; Justin Richer
>     >>>>> <mailto:[email-masked] <mailto:[email-masked]>>;
>     Maciej Machulak
>     >>>>> <mailto:[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     >>>>> <mailto:[email-masked] <mailto:[email-masked]>>
>     >>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >>>>>>
>     >>>> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> email: [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Wed, 16 Jul 2014 12:24:11 -0400

May/June of 2010 OpenID Connect and OpenID artifact binding merged to crate a spec based on top of OAuth 2.

Aug 2010 there was a ID called "OAuth Dynamic Client Registration Protocol" http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00 that included discovery (XRD) published by Eve, Maciej and Chriatian that was used by UMA.  
 
The early model largely used a pull model to validate the identity of the client registering. eg The AS pulled down a file of JSON in a effort to validate an identity for the UMA client.
It did have amongst several methods one that was a client push.

Around May of 2011 I did the initial Connect dynamic client registration posting a JSON object with values to a registration endpoint and getting back a client_id and secret.
We went back and forth several times on Key value vs JSON requests over the spec's development.

In there initial forms it is true that the client winds up with a client_id and client secret, but I don't think they were in any way wire compatible.
Looking at it the parameter name "redirect_uri" (taken from the OAuth spec is the same but the values are different one is a string and the other an array of strings.

At a Connect WG meeting at IIW (fall 2011) with Eve who I believe is or was a Connect WG member from PayPal and I came up with making the registration endpoint OAuth protected with an initial acces token to provide the possibility of identifying the registrant, as that was part of the UMA use case.   That enabled UMA to I believe drop the pull registration and align more with Connect registration, as well as adopt Connect semantics in some other parts of UMA for compatibility.  

That was added to the Connect in Oct/Nov 2011.  There were lots of other things like client secret key rotation that were in the Connect version but were taken out and moved to a management draft in the end and not put in the final connect version.

In May of 2012 Justin, Eve, Thomas & Mache published a 00 ID that was a copy of the UMA .

That was updated over I think 18 versions to get to what we have now.   Including input from Phil/Tony on software statements.

So in the way of the IETF a number of groups with initial documents covering similar use cases came together in a working group and a document was produced that satisfied multiple use cases so that adoption and interoperability of OAuth 2 could happen.

Yes one of the inputs is the 00 draft that was used by UMA before I think they migrated to the connect version.   I don't know what the UMA specs currently reference.

I think referencing the earlier ID  and giving credit to the earlier authors is fair.  

John B.