I would agree with Phil, the server makes right in this case, specific statement may be sent but the processed statement is returned which may be different
-----Original Message----- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Thursday, February 6, 2014 10:39 AM To: Phil Hunt Cc: oauth@ietf.org list Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! I think it would be echoing back the software statement that was processed as part of the request for consistency. 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
