Thanks for the notes, Hannes. I didn't speak up on the call at all because it honestly left me a bit confused. For the first 3/4 or so I was trying to figure out what the problem was that everyone was fighting about. Phil, Tony, and others seemed to be pointing out that "in all of these cases that we can tell you about, it doesn't make sense to do DynReg". That is fine. That's not a problem; that just reflects the fact that there are different use cases out there that may not need this OPTIONAL part of the spec suite.
After that there seemed to be some consensus (at least among those that were bringing up the original complaints) that folks would like to see a smaller core document, with all of the optional parts removed to one or more extensions. I'll grant that the DynReg draft has gotten long and there are a lot of optional pieces. Maybe it makes sense to break it out; at the very least I think it's worth trying. Perhaps more of the WG would accept it if that was the case. I believe Tony commented that "if something is optional, it means that ALL servers everywhere have to support it". I don't understand that - the requirement for servers to ignore (i.e., don't throw an error or fall over) if a client sends over a parameter it doesn't understand has always been part of the core OAuth 2.0 spec. It's not a new idea. There was also a comment that the WG doesn't have a lot of experience with this domain. That's true, but the experience the WG *does* have is with the UMA and OIDC use cases, which directly fed into the current draft. DynReg v14 is sufficient for the two major classes of *real*, deployed and under development, non-hypothetical use cases that we know of today. We can't loose sight of this fact. If there is something missing from the current draft, or something present that disallows a particular requirement, I'd ask the other WG members to please present those requirements and problems clearly so that we can discuss them. So far I haven't seen anything concrete in this area. I've heard a lot of contention and fighting but I can't make out what the actual problem statement is. Phil's software statements/assertions seems to fit well as an extension; it's not prohibited by anything existing in the draft. *apologies if I misattributed comments; I can recognize most of the voices that were on the call but not all of them. --Amanda On 8/23/13 4:24 AM, "Hannes Tschofenig" <hannes.tschofe...@gmx.net> wrote: >Thank you all for joining yesterday's conference call. I took some notes >during the call. > >---- Meeting Minutes ---- > >Participants: >- William Kim >- John Bradley >- Antonio Sanso >- Mike Jones >- Phil Hunt >- Justin Richer >- Hannes Tschofenig >- Derek Atkins >- Amanda Anganes >- Morteza Ansari >- Brian Campbell >- Thomas Hardjono >- Prateek Mishra >- George Fletcher >- Tony Nadalin > >Minutes > >Justin started with a discussion about what is described in Section 1.3 >of the protocol specification and Appendix B describes the use cases. > >Dynamic client registration is one way to introduce a client to an >authorization server. >A client is the relationship between a client piece software and a piece >of software on the authorization server side. >The client needs a client_id and the authorization server needs to get >various other piece of information (such as a redirect_uri, display_name). > >The group then started a discussion about what the minimal amount of >information is the authorization server needs to have. > >The discussion then shifted to uses cases where trust is established >a-priori (out-of-band) and is conveyed via an assertion to the dyn-reg >exchange (protected registration) and the case where there is no trust >(=open registration); the latter case would push the obligation to the >user. > >There seems to be agreement (on the call) that both use cases are valid. > >The following examples for protected registration have been discussed: > > * manual page where the developer obtains a developer key and register >there; they end up with an initial access token (in the form of an >bearer token) > * UMA case where there is someone who is introducing the two parties >to each other. (Currently not described in the document) > * Developer Automation: Who holds the client registration information? >The developer makes the call and you get the client_id back. The client >is not doing the dyn. registration. (This use case is described in >Appendix B.3) > * John's use case: >http://www.ietf.org/mail-archive/web/oauth/current/msg12008.html > >Phil Hunt starts with his presentation slides, which he had distributed >to the mailing list earlier: >http://www.ietf.org/mail-archive/web/oauth/current/msg12007.html > >Phil says that the client_id does not need to be provided by the AS - it >could be provided by the client. John says that the client_id has to be >tied to the redirect_uri since otherwise attacks are possible. > >Phil says we are lacking good terminology for client, and for client >instance. > >George claims that the client instance concept came up when mobile >clients and Web clients got mixed in deployments and people wanted to >have a way to distinguish the two since they were different in their >ability to keep a secret. > >A discussion started about whether an evolution had happened regarding >different types of clients. The client id is a proxy for some release of >some software. Someone claimed that with dynamic client registration we >have the ability to turn public clients back into confidential clients. > >Phil argues that service providers want to know the class of >applications and the instances. A problem with a client can be a >compromise and you want to disable it. There may also be a bug in the >software and then one may want to disable the entire class of clients. > >Phil asks whether we expect that JavaScript code registers every time >the code runs. The response was clear that this is not the expectation. > >Phil then goes on to explain four levels of dynamic behavior: > > * Client developer hardcodes the address of the authorization server >and other information. > * Developer may hardcode some information but the client may >dynamically interact with the authorization server to provide additional >information (suggested by John) > * Confirmation information in the client software can be used to >dertermine which server to talk to and which parameters to use > * Client software decides at runtime who to contact and what >information to provide > >Hannes stopped the discussion because we ran out of time and started a >discussion about where we could go next. > >Justin said that he has not seen anything that is not supported yet. >Tony, Phil, and Prateek say that we are trying to find the minimum >supported information. > >It seems that different folks have different use cases in mind. Can this >situation be solved with extensions? Phil claims that the current >specification is overly complex. > >It is clear that we cannot have one single spec that covers all the use >cases. >Are we arguing which use cases are covered in the base specification? > >Tony suggested that only client_id and redirect_uri should be the >supported and everything else should be dropped. > >Justin responded that the rest is optional anyway. > >Discussion started about what "optional" means. Does the authorization >server have to implement to implement even optional components? > >John says that we need a new feature for adding and removing a new >endpoint. This is a common use case and we don't want to revoke all the >permissions when we do so. > >Mike says that there is some additional material needed beyond client_id >and redirect_uri. >John agrees. > >Prateek says that we need to identify a minimal subset and have >extensions defined. > >Hannes will talk to Derek about the next steps. Expect another >conference call soon. > >Phil will update the software assertion document. > > >_______________________________________________ >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
