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
