Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

[Phil Hunt <[e-mail]>]

See below

Phil

On 2013-08-19, at 22:34, Torsten Lodderstedt <[e-mail]> wrote:

> Hi Phil,
> 
> 
> 
> 
>> The assumption that client id must be issued by the sp seems wrong to
>> me in many cases-- including oidc. 6749 does not make this restriction
>> at all.
> 
> What do you mean? Grant type code requires a client_id in order to identify the client at the AS's authz endpoint. Based on this data, the AS chooses the authz policy and validates the redirect_uri.

[ph] yes. But i am referring to the fact that the client does not have to obtain it from the as. It merely has to present one that is accepted. 

Iow a federated assertion might solve the issue. 
> 
>> 
>> Given this, a statement approach may be sufficient for many clients. No
>> need for long term credential mgmt or records.
> 
> Perhaps for clients using the token endpoint only.

[Ph] Actually I was also thinking of javascript clients. 
> 
> regards,
> Torsten.
> 
>> 
>> Phil
>> 
>> On 2013-08-19, at 16:33, Eve Maler <[e-mail]> wrote:
>> 
>>> Hi folks-- Just a reminder that the first draft the UMA group
>> submitted on May 1, 2011 contained extensive requirements and use cases
>> related to UMA's various needs for dynamic client registration:
>>> 
>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00
>>> 
>>> When there was interest to pick up this draft as a WG work item, it
>> was recommended that we excise this content so that the doc wouldn't be
>> so specific to our particular usage of OAuth.
>>> 
>>> I point this out just to show that the need for dynamic client
>> registration isn't limited to OpenID Connect, and that some specific
>> use cases have already been floated here.
>>> 
>>> FWIW,
>>> 
>>>   Eve
>>> 
>>> On 19 Aug 2013, at 8:31 AM, Justin Richer <[e-mail]> wrote:
>>> 
>>>> All of this is a good argument to do both, which is what I've been
>> saying all along.
>>>> 
>>>> -- Justin
>>>> 
>>>> On 08/19/2013 11:33 AM, Phil Hunt wrote:
>>>>> I do not recall agreement in charter discussions to solving a
>> specific case.
>>>>> 
>>>>> I recall more than one in the re-chartering discussion said dyn reg
>> needed major changes to solve their use cases.
>>>>> 
>>>>> Phil
>>>>> 
>>>>> On 2013-08-19, at 8:18, Justin Richer <[e-mail]> wrote:
>>>>> 
>>>>>> Tony, I completely disagree. The proposals that I've seen have
>> different means and different end states, and they make different
>> assumptions about the relationship between entities and the
>> capabilities of all players.
>>>>>> 
>>>>>> -- Justin
>>>>>> 
>>>>>> On 08/19/2013 11:15 AM, Anthony Nadalin wrote:
>>>>>>> There are proposals out there that are trying to solve the same
>> problem, but in different ways, so I would not say that they are trying
>> to solve different use cases. I do think that we need to make sure that
>> whatever proposal we select it needs to have a wide range of use cases
>> it solves, not just a single use case as the more solutions this group
>> produces the more confused folks will be
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Justin Richer
>>>>>>> Sent: Monday, August 19, 2013 7:27 AM
>>>>>>> To: Phil Hunt
>>>>>>> Cc: oauth mailing list
>>>>>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference
>> Call: Thu 22 Aug, 2pm PDT
>>>>>>> 
>>>>>>> I agree that dynamic registration isn't needed to solve *all* of
>> the different use cases. It solves its set of specific problems (and
>> does so well, if you ask me), but there are and will always be things
>> that it won't work for, and that's fine. That's why I've suggested
>> under a separate thread that the other drafts go forward separately and
>> that DynReg not be hung up on them. We're fundamentally solving
>> different use cases, and there is no magic solution that will solve all
>> the problems at once.
>>>>>>> 
>>>>>>> -- Justin
>>>>>>> 
>>>>>>> On 08/18/2013 08:15 PM, Phil Hunt wrote:
>>>>>>>> I think we should start by reviewing use cases taxonomy.
>>>>>>>> 
>>>>>>>> Then a discussion on any client_id assumptions and actual
>> requirements for each client case. Why is registration needed for each
>> case?
>>>>>>>> 
>>>>>>>> The statement can solve some complication but should be put in
>> context of use cases.
>>>>>>>> 
>>>>>>>> Phil
>>>>>>>> 
>>>>>>>> On 2013-08-18, at 15:01, Hannes Tschofenig
>> <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>> Hash: SHA512
>>>>>>>>> 
>>>>>>>>> - -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>> Hash: SHA512
>>>>>>>>> 
>>>>>>>>> Based on your feedback via the poll let us start with August
>> 22nd with the first conference call. I will distribute the conference
>> call details on Tuesday.
>>>>>>>>> 
>>>>>>>>> Let us talk about the agenda. There were several items brought
>> up in
>>>>>>>>> discussions, namely
>>>>>>>>> 
>>>>>>>>> * Software assertions / software statements
>>>>>>>>> 
>>>>>>>>> We briefly discussed this topic at the IETF OAuth session but
>> we may need more time to understand the implications for the current
>> dynamic client registration document:
>> http://www.ietf.org/proceedings/87/slides/slides-87-oauth-2.pptx
>>>>>>>>> 
>>>>>>>>> * SCIM vs. current dynamic client registration approach for
>>>>>>>>> interacting with the client configuration endpoint
>>>>>>>>> 
>>>>>>>>> In the past we said that it would be fine to have a profile
>> defined in SCIM to provide the dynamic client registration for those
>> who implement SCIM and want to manage clients also using SCIM. It
>> might, however, be useful to compare the two approaches in detail to
>> see what the differences are.
>>>>>>>>> 
>>>>>>>>> * Interactions with the client registration endpoint
>>>>>>>>> 
>>>>>>>>> Justin added some "life cycle" description to the document to
>> motivate some of the design decisions. Maybe we need to discuss those
>> in more detail and add further text.
>>>>>>>>> Additional text could come from the NIST Blue Button / Green
>> Button usage.
>>>>>>>>> 
>>>>>>>>> * Aspects that allow servers to store less / no state
>>>>>>>>> 
>>>>>>>>> - - From the discussions on the list it was not clear whether
>> this is actually accomplishable with the current version of OAuth. We
>> could explore this new requirement and try to get a better
>> understanding how much this relates to dynamic client registration and
>> to what extend it requires changes to the core spec.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> What would you like to start with? Other topics you would like
>> to bring up?
>>>>>>>>> - -----BEGIN PGP SIGNATURE-----
>>>>>>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>>>>>>>>> Comment: GPGTools - http://gpgtools.org
>> iQEcBAEBCgAGBQJSEULvAAoJEGhJURNOOiAtttEH/Aogg8Q/R/L9/mzU05IQbnze
>> AdXB1ZvySkV3jZT4I5shmP7hQr6mc6P6UdvyOrSjrvPlBHen55/oa5z7Cwchd1dk
>> dcDUEavbodjnm9SrOs0nKaTvdeZimFSBkGMrfhoTYLXpymP24F9PZgwUXdOcFocF
>> OiCs3qDajYaA395DCg5+4mOLQQgDnmy4drlgj2NPv1nMBRDBubzgAhJccwF2BLN9
>> IW7MAwTEu7vYT/gwIFzriPkui7gYpf8sAqsnzf/z7FtXbsP8imgOKUlQxzZzeSSP
>> QEb6+syyMD9Gt6wxQfWzyl5T0bYLP6DQ+ldZR8yGKCwb+2k3LN6Q8bIpj4mIERI=
>>>>>>>>> =tkGT
>>>>>>>>> - -----END PGP SIGNATURE-----
>>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>>>>>>>>> Comment: GPGTools - http://gpgtools.org
>> iQEcBAEBCgAGBQJSEUQfAAoJEGhJURNOOiAt8wkIAI3xgdsWuOB36KLiMLRUG+Zb
>> RvYqV+rOH80m7YVJcdOLjQJcpPqOIBdzq/yuNiAaF1uFJCqBn97ZQ/NLXLNGcg8x
>> wI/Laz7kP2U4B2trBTMtAf2wsY9uYw4Eh+eOEDKGF6cmkEzrzrlw4q/Sfu6vy181
>> VI+kqwzZ+iYX4iL3NYPlkg3rwF4OZ1v3T08Erg2SPrbmNd1TRfJJU8HrYFEJQo1q
>> p0RiLjcFFDCEZs0gDr9zliCXllV7J9h2ttqLq8+xwPATDuO6buQdFS9vZQ8t1u36
>> a0FIuy3NM8PQbblC3B5WumUjW4kntLV09ytYV8h6S8C/dgFwMqzAwEAeNx1exyE=
>>>>>>>>> =3qNI
>>>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> Eve Maler                                 
>> http://www.xmlgrrl.com/blog
>>> [phone]                        
>> http://www.twitter.com/xmlgrrl
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>