Yes that is what I confirmed with Mike. On Feb 6, 2014, at 4:54 PM, Phil Hunt <phil.h...@oracle.com> wrote:
> Yes. Mike and I did agree on this. > > To confirm I have understood it,I thought I would send this so that we have a > record of why we went with returning the statement (cause I know I'll forget > in the future) :-) > > I was concerned that returning the software statement (which was an input > value) does not necessarily reflect the final registration state selected by > the service provider. For example, the AS may have selected a particular > authentication mode. I was worried that returning the statement then might > present some confusion compared to the registration profile the server has > created. It is not that I was advocating to not return the statement, it was > that I was advocating the values from the statement that were accepted be > included in the main registration profile returned (the statement would then > be redundant). > > ==> However, Mike made an excellent point that the statement could also be > considered in part to be an authorization. Thus it is useful to retain the > statement as a record of authorization (not just of the metadata values > requested). > > So in the case where values in the statement appear to duplicate values in a > request or resonse here is the logic: > * in the request, metadata in the statement overrides metadata in the request > itself, > * in the response, metadata in the response reflects what the server accepted > and thus overrides any conflicting metadata in the original statement which > is also returned. > > Have I got that right? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > On 2014-02-06, at 11:17 AM, 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
