Two ways to handle complexity here. Reading over the minutes, I'm not sure it was clear the main point of observation I am trying to make to the group.
The current design assumes that every client is somehow completely different as the majority standing. This has lead to a design where all protocol related values and informational values must be provided at "association" time. We've tried to apply this specification with this model against a number of use cases, and my chief problem is three-fold: 1. Amount of data that must be retained per client (with no way to tell for how long) 2. On a per client basis, it is unclear what each client must do to successfully register. The spec presumes a lot of prior knowledge as to what is required and what isn't. 3. Instead of just issuing one credential (client cred), the spec issues 2 and defines another. Three special case security credentials each with special handling. I have no doubt that many have successfully implemented this. But the concern is that the number of APIs tested and in production is extremely low. I am proposing 2 observations that MAY make the eventual solution much much much easier to implement and operate. a. In most cases, client software is not custom. Custom software is an edge case (that must be supported). Most client software can be grouped together as software distributions (software downloaded from a common site as a common distribution). If we call this a software 'class', then we can observe that for a particular software class, there MAY be one or more instances of a class associating with any particular AS. For any particular AS, the only thing that might change about the client is the redirect_url -- and this is likely only for web apps, not native apps. b. If you look at the categories I presented yesterday, and in particular the last slide. You can notice that the solution for each category is relatively trivial and clearly defined. Categorization of clients seems like complexity at first. But once you look at it, you see that the decision path for developers is very clear. Once a developer decides what type they are, the methodology is clear. Finally, I believe that re-framing into "classes" and "categories" will also handle, in a better way, the cases for UMA and OIDC which are also at one end of a spectrum of associations (static vs. dynamic). At one end, static clients are hard-coded to a particular AS, next clients that associate upon installation, to OIDC clients that associate on an ongoing configuration basis (like imap clients), to UMA which may associate on a per-event basis. To avoid more discussion continuing to go in circles, it seems time I put forward a draft for the group to consider. While this may present changes to the method of registration, I hope you will agree that it is much simpler. Thanks in advance for your patience, thoughts, and ideas. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-23, at 1: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
