OK On Feb 6, 2014, at 4:17 PM, Mike Jones <michael.jo...@microsoft.com> wrote:
> I just spoke to Tony about this in person and to Phil about it on the phone. > We're all good with having the server return the actual values used in the > registration (which is what the spec already does). > > -- Mike > > -----Original Message----- > From: John Bradley [mailto:ve7...@ve7jtb.com] > Sent: Thursday, February 06, 2014 11:08 AM > To: Phil Hunt > Cc: Mike Jones; oauth@ietf.org list > Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! > > Telling the client the state of it's configuration is useful to the client if > the server "makes right". > > I think Tony is arguing for the server putting the entire response into the > software statement element in the response. Where at the moment the spec > provides those elements at the top level of the JSON object along with > client_id etc. > > My question for Tony is if he is thinking that the made right software > statement in the response would be signed by the AS as opposed to the > original that was signed by the Software publisher, and if so what is the > client going to do with it? > > John B. > > On Feb 6, 2014, at 3:52 PM, Phil Hunt <phil.h...@oracle.com> wrote: > >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> On 2014-02-06, at 10:38 AM, John Bradley <ve7...@ve7jtb.com> wrote: >> >>> I think it would be echoing back the software statement that was processed >>> as part of the request for consistency. >> >> FWIW -- I don't really think anything should be returned other than the >> client_id and client creds and the location of the RESTful object created if >> available (the one accessible via the management api). >> >> Assume you man consistency with REST. If that is the case, then what the >> server should respond with is the processed registration (the final state). >> I see the statement as an input to the registration profile that gets >> created. A statement is not the completed registration. Many clients share >> the same statement, but only one registration exists per instance. A >> registration would have all of the input values plus any generated data like >> client_id and credentails. >> >> But as I said, I'm not sure why the client needs to see anything other than >> the client_id and credentials in the response other than to be "RESTful" in >> some way. >> >> >>> Replying with a different software statement is going to be too confusing. >>> >>> The entirety of the reply represents the configured state for the client. >>> >>> John B. >>> >>> On Feb 6, 2014, at 3:33 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>> >>>> My thought was the original statement shouldn't be returned because the >>>> server would return the "processed" information. IOW reflecting what it >>>> took from the certificate vs. from the registration request. >>>> >>>> If you just echo back the certificate you aren't necessarily reflecting >>>> the final state of the registration. >>>> >>>> I'm pretty open on this. Just want to make clear on what state we are >>>> returning (if any). >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> On 2014-02-05, at 6:11 PM, Mike Jones <michael.jo...@microsoft.com> wrote: >>>> >>>>> Oh, I should add that I disagree that it's not necessary to return the >>>>> software statement. It's a key part of the client registration >>>>> information, and so should be returned like the other client registration >>>>> information actually used. >>>>> >>>>> -- Mike >>>>> >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones >>>>> Sent: Wednesday, February 05, 2014 6:08 PM >>>>> To: Phil Hunt; Eve Maler >>>>> Cc: oauth@ietf.org list >>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! >>>>> >>>>> Thanks for your comments, Phil. I'm working on addressing them at >>>>> present. >>>>> >>>>> One comment confuses me. You wrote "Section 4.1 - It would be good to >>>>> have an example with a software statement and no initial access token (or >>>>> both)." Yet the last example in Section 4.1 already is such as an >>>>> example (taken from draft-hunt-oauth-client-association, actually). Was >>>>> there something else that you were thinking of? >>>>> >>>>> Also, the "Deployment Organization" definition *does* describe when it >>>>> and the deployment organization are different. Where I think that the >>>>> text describing the choices for the two cases belongs is a subsection of >>>>> the Use Cases appendix. Do you want to write text about the two cases, >>>>> Phi? >>>>> >>>>> -- Mike >>>>> >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt >>>>> Sent: Monday, February 03, 2014 12:18 PM >>>>> To: Eve Maler >>>>> Cc: oauth@ietf.org list >>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! >>>>> >>>>> I am generally in agreement on the new drafts. Thanks Mike! >>>>> >>>>> Here are some comments: >>>>> >>>>> In the software statement section 3: >>>>>> If the authorization server determines that the claims in a software >>>>>> statement uniquely identify a piece of software, the same Client ID >>>>>> value MAY be returned for all dynamic registrations using that >>>>>> software statement. >>>>>> >>>>>> In some cases, authorization servers MAY choose to accept a software >>>>>> statement value directly as a Client ID in an authorization request, >>>>>> without a prior dynamic client registration having been performed. >>>>>> The circumstances under which an authorization server would do so, >>>>>> and the specific software statement characteristics required in this >>>>>> case, are beyond the scope of this specification. >>>>>> >>>>> >>>>> We should call out that the server MAY also issue per instance >>>>> client_id's (the opposite of the first quoted paragraph above) if it >>>>> chooses to use client_id as an instance identifier (the software_id >>>>> identifies what clients are based on the same software). I think this >>>>> will be the typical use case. Not sure whether the first paragraph should >>>>> be re-written, or a new one added. >>>>> >>>>> Section 4.1 >>>>> It would be good to have an example with a software statement and no >>>>> initial access token (or both). >>>>> >>>>> Section 5.1 >>>>> Should we also say that is not necessary to return the software >>>>> statement. Note: the server should return the meta data that was >>>>> obtained from the statement. >>>>> >>>>> Dyn-Reg-Metadata >>>>> The metadata document looks fine. I would prefer it being included in >>>>> dyn reg, but can live with it as is. >>>>> >>>>> Dyn-Reg-Management >>>>> I'd like to discuss this more in London. I think a SCIM based management >>>>> API may be simpler to write up and can leverage the features of SCIM >>>>> without having to redefine them in a new API. Still, SCIM is a way off >>>>> from approval -- so I understand the need to move forward now. Is >>>>> experimental the right way to go? I am not sure. >>>>> >>>>> Glossary >>>>> The terms Software API Publisher and Software API Deployer are defined >>>>> but never used, Specifically the text describing the issue of when these >>>>> are two distinct entities is missing. When publisher and deployer are the >>>>> same (eg. as with Facebook), the dynamic registration need is minimal >>>>> since a client_id can be issued from a single domain. When publisher and >>>>> deployer are different, such as with OpenID Connect, SCIM, then the >>>>> client developer cannot pre-register for a client_id at development time. >>>>> >>>>> >>>>> The software statement is an optional mechanism that enables developers >>>>> to pre-registrater to obtain a signed statement (instead of a client_id) >>>>> so that API deployers can recognize the pre-registration relationship >>>>> with the publisher. Of course, software statements are optional if you >>>>> don't need to be able to recognize what the client is. (apologies if I >>>>> have not phrased the issue optimally) >>>>> >>>>> Maybe if we can put in a couple of paragraphs explaining this >>>>> distinction? >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.h...@oracle.com >>>>> >>>>> On 2014-01-30, at 7:33 PM, Eve Maler <e...@xmlgrrl.com> wrote: >>>>> >>>>>> Hi Hannes-- The UMA Core spec currently points directly to the basic >>>>>> dynamic client reg doc with MAY statements, and is agnostic as to usage >>>>>> of the higher-order functions. (These turn into optional interop feature >>>>>> tests.) So I think it's fair to say that the split has no structural >>>>>> problems from an UMA perspective. >>>>>> >>>>>> Eve >>>>>> >>>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig >>>>>> <hannes.tschofe...@gmx.net> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> as you have seen from the meeting minutes of our recent status chat >>>>>>> it is time to proceed with the dynamic client registration work. >>>>>>> >>>>>>> The earlier version of the dynamic client registration document was >>>>>>> split into three parts, namely >>>>>>> (1) the current working group draft containing only minimal >>>>>>> functionality, >>>>>>> (2) a document describing meta-data, and >>>>>>> (3) a document containing management functionality. >>>>>>> >>>>>>> This change was made as outcome of the discussions we had more or >>>>>>> less over the last 9 months. >>>>>>> >>>>>>> The latter two documents are individual submissions at this point. >>>>>>> New content is not available with the recent changes. So, it is one >>>>>>> of those document management issues. >>>>>>> >>>>>>> I had a chat with Stephen about WG adoption of the two individual >>>>>>> submissions as WG items. It was OK for him given that it is a purely >>>>>>> document management action. However, before we turn the documents >>>>>>> into WG items we need your feedback on a number of issues: >>>>>>> >>>>>>> 1) Do you have concerns with the document split? Do you object or >>>>>>> approve it? >>>>>>> 2) Is the separation of the functionality into these three documents >>>>>>> correct? Should the line be drawn differently? >>>>>>> 3) Do you have comments on the documents overall? >>>>>>> >>>>>>> We would like to receive high-level feedback within a week. We are >>>>>>> also eager to hear from implementers and other projects using the >>>>>>> dynamic client registration work (such as OpenID Connect, UMA, the >>>>>>> BlueButton/GreenButton Initiative, etc.) >>>>>>> >>>>>>> For more detailed reviews please wait till we re-do the WGLC (which >>>>>>> we plan to do soon). We have to restart the WGLC due to discussions >>>>>>> last years and the resulting changes to these documents. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>> >>>>>>> PS: Derek and I also think that Phil should become co-auhor of these >>>>>>> documents for his contributions. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
