in line Phil @independentid www.independentid.com phil.h...@oracle.com
> On Jan 13, 2015, at 3:08 PM, Richer, Justin P. <jric...@mitre.org> wrote: > > Hi Hannes, thanks for the review. Comments inline. > > On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > >> Hi Justin, Hi all, >> >> as noted in my status update I am trying to finalize the pending items. >> >> Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my >> review of draft-ietf-oauth-dyn-reg-management raised some questions >> about the terminology. >> >> If you look at the structure of the ToC then you will notice the following: >> >> 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13 >> 3.1. Client Registration Request . . . . . . . . . . . . . . . 14 >> 3.1.1. Client Registration Request Using a Software >> Statement . . . . . . . . . . . . . . . . . . . . . . 15 >> 3.2. Client Registration Response . . . . . . . . . . . . . . 16 >> 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 16 >> 4.1. Client Information Response . . . . . . . . . . . . . . . 17 >> 4.2. Client Registration Error Response . . . . . . . . . . . 18 >> >> There is no 'Client Registration Response' in the protocol (only the >> Client Information Response) and section 3.2 is pretty much empty and >> only points to the later sections. So, I would suggest to do the following. >> >> 3. Client Registration Endpoint >> 3.1. Client Registration Request >> 3.1.1. Client Registration Request Using a Software Statement >> 3.2. Client Registration Response >> 3.2.1. Client Information Response >> 3.2.2. Client Registration Error Response >> >> (A section with only a single sub-section is also a sign of a bad >> structure.) >> > > I'm actually OK with this re-organization, as long as there's no objection > from the WG at this stage. I think what we have might be slightly vestigial > of the existing document. There *is* a client registration response, but it's > one of two things: the information or error response. Collapsing them as > above will likely make that section easier to read. Thoughts? > >> I re-read the terminology and looked at Figure 1 to see whether it makes >> sense and it still does not. I know that there may be many different >> deployment options but it should at least be clear to the reader where >> information comes from and where does it go. >> >> For example, when I try to follow the flow of the software statement >> then I read the following: >> " >> Software Statement: In some cases, a software statement will be issued >> directly by the organization or developer that creates the client software. >> " >> >> What does the figure tell us? It shows us that the client or developer >> gets the software assertion. >> >> +--------(A)- Initial Access Token (OPTIONAL) >> | >> | +----(B)- Software Statement (OPTIONAL) >> | | >> v v >> +-----------+ +---------------+ >> | |--(C)- Client Registration Request -->| Client | >> | Client or | | Registration | >> | Developer |<-(D)- Client Information Response ---| Endpoint | >> | | +---------------+ >> +-----------+ >> >> Maybe we should illustrate one example that makes sense and then say >> that there are others that could be used. > > The examples are included in Appendix A. > >> It also does not make sense to >> show the developer in the box together with the client since the >> developer does not execute a protocol exchange with the client >> registration endpoint. > > That's not true, a developer (person or organization) could very easily be > using the dynamic registration protocol on behalf of the software that > they're developing. This is actually used in practice in a number of places, > and if you'd like a concrete example just go to the MIT integration test > site: https://mitreid.org/manage/dev/dynreg (log in with user/password). IMO. This defeats the purpose of dynamic registration. A developer that wants to hand register would go through the SP’s developer support pages as they do now. It also won’t work in cases where an individual client will negotiate a client key (where the actual key is not shared and thus the developer (or any other MITM) can’t get in between. > >> >> Here is a proposal for improving this: >> >> >> FROM: >> >> +--------(A)- Initial Access Token (OPTIONAL) >> | >> | +----(B)- Software Statement (OPTIONAL) >> | | >> v v >> +-----------+ +---------------+ >> | |--(C)- Client Registration Request -->| Client | >> | Client or | | Registration | >> | Developer |<-(D)- Client Information Response ---| Endpoint | >> | | +---------------+ >> +-----------+ >> >> Figure 1: Abstract Dynamic Client Registration Flow >> >> TO: >> >> +-------- O -- (A)- Initial Access Token (OPTIONAL) >> | /|\ >> | +---- / \ -- (B)- Software Statement (OPTIONAL) >> | | Client >> | | Developer >> | | >> v v >> +--------------+ +---------------+ >> | |--(C)- Client Registration Request -->| Client | >> | Client | | Registration | >> | |<-(D)- Client Information Response ---| Endpoint | >> +--------------+ +---------------+ >> >> Figure 1: Abstract Dynamic Client Registration Flow >> >> >> Alternatively, one could also separate the distribution of software >> statements and the actual protocol exchange. Here is the proposal: >> >> +--------(A)- Initial Access Token (OPTIONAL) >> | >> | +----(B)- Software Statement (OPTIONAL) >> | | >> v v >> +-----------+ +---------------+ >> | |--(C)- Client Registration Request -->| Client | >> | Client | | Registration | >> | |<-(D)- Client Information Response ---| Endpoint | >> +-----------+ +---------------+ >> >> Figure 1: Abstract Dynamic Client Registration Flow >> >> >> +---------------+ >> | Authorization | >> | Server | >> +---------------+ >> | Initial >> |(A) Access >> | Token >> v >> O Client >> +------ /|\ Developer >> |+----- / \ >> || >> (A)||(B) Software >> || Statement >> vv >> +-----------+ >> | | >> | Client | >> | | >> +-----------+ >> >> Figure 2: Software Statement / Initial Access Token Distribution Example. >> > > This is inaccurate, as described above. I believe we should leave this as is. > >> Then, there is also this statement in the Software Statement definition: >> >> " >> In other cases, a >> software statement will be issued by a third party organization >> for use by the organization or developer that creates the client >> software. >> " >> >> In the terminology section we are defining all the parties that are >> involved and now this mysterious "third party organization" is >> introduced. Is this one of the already defined parties or is this yet >> another organization? > > This is just exemplary text, saying one way that it could happen. The > "mysterious" third party organization is someone who is not the authorization > server or software API publisher who issued the statement (those cases are > covered by the preceding sentence). They're not a named party, it's just > "whoever made the software statement". We are not specifying which software > statements the AS decides to trust, since that's a policy decision outside of > our control as spec authors. Many authorization servers will only trust > software statements that they issue, but others will have a configured set of > third parties that they will accept software statements from, probably as > part of a trust framework. I think this text should be left as it is unless > there's a way to word this so that it doesn't sound like we're adding another > explicitly named party to the mix. > >> >> Finally, the client developer is defined as a single individual or an >> entire organization (i.e., a group of people). However, in the text you >> write 'client developer or organization'. For example, look at the >> software statement: >> >> "In some cases, a software statement will be issued directly by the >> organization or developer that creates the client software. >> " >> >> Wouldn't it be more consistent to use the client developer definition as >> is and just turn this sentence into >> >> " >> In some cases, a software statement will be issued directly by the >> client developer. >> " >> > > Since "developer" can mean individual or organization, I'm fine with this > simplifying change as long as there's no objection from the WG. > > Thanks again for the review. > -- Justin > _______________________________________________ > 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
