+1 The chosen solution should account for this.
Phil On 2013-08-20, at 2:34, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi Phil, > > I agree, the client may also present a client_id obtained from another > "source". But: the AS must be able to associate a policy with this particular > id. This typically requires a provisioning of the client id before the actual > OAuth interaction takes place. Otherwise the AS does not have any information > regarding the client id in the code flow at authz endpoint. > > This needs to be taken into account. > > regards, > Torsten. > > Am 20.08.2013 um 08:12 schrieb Phil Hunt <phil.h...@oracle.com>: > >> Sorry i see my message still isn't that clear. I am saying there is no >> requirement that a client directly obtain a client_id from the as service >> provider. It is merely an assumption that has been made by dyn reg based on >> typical use patterns to date. >> >> It could be reasonable for a client to generate it's own guid or more >> likely, use an assertion signed by a party the service provider trusts. >> >> Phil >> >> On 2013-08-19, at 22:53, Phil Hunt <phil.h...@oracle.com> wrote: >> >>> See below >>> >>> Phil >>> >>> On 2013-08-19, at 22:34, Torsten Lodderstedt <tors...@lodderstedt.net> >>> 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...@xmlgrrl.com> 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 <jric...@mitre.org> 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 <jric...@mitre.org> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 >>>>> <hannes.tschofe...@gmx.net> 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 >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> Eve Maler >>>>> http://www.xmlgrrl.com/blog >>>>>> +1 425 345 6756 >>>>> http://www.twitter.com/xmlgrrl >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
