-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Here are my notes.
- - ---- Meeting Minutes ---- * Participants - - - Justin Richer - - - Hannes Tschofenig - - - John Bradley - - - Tony Nadalin - - - Derek Atkins - - - Mike Jones - - - Phil Hunt (joined later) * Minutes Justin explained the document split with a "core" and a "management" document: http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00 http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 The core document defines the client registration endpoint with a minimal set of parameters. The management spec defines extended meta data useful for human-facing authorization. There is also the client configuration endpoint defined. It is a document re-structuring exercise. Justin explained what he considers the minimum set of parameters. The claims that the minimum set of parameters have to be considered in context of what flow you are using. He provides those details in Section 2 of the core document. The group started a discussion about assertion usage and Tony agreed to produce a writeup to explain to others what it means. Justin pointed to a mail by George on the list that Tony and the group should have a look at. Here is the link: http://www.ietf.org/mail-archive/web/oauth/current/msg12099.html Justin noted that the stateless registration use case is currently described in the latest draft (in the core document, Appendix B.2). That use case writeup was provided by John. John said that we could add some more detailed examples of how it would be implemented but it is a rather implementation specific detail, i.e., authorization server internal aspects. Justin stated that what we don't have yet is a complete e2e interoperable description of stateless registration. John responded that we could add that description to the use cases. The problem is that some people take the examples as the only way to do it. He said that we could compare it with the OAuth core, which does not define what the access token is. That does not prevent us from defining extensions using JSON and other formats. There are good use cases for the different token formats. John added that there is likely a need for a profile for how to do dynamic client registration endpoints in a federation concept. That's another step beyond the basic dynamic client registration. John switched topic and raised a question saying that we have a lot of disagreements about the software assertions. Some of us think that this is isomorphic to the initial access token. Would moving that initial token into a claim into the JSON object rather than content in the HTTP header help to deal with some of the disagreements? No response. John asked Tony directly whether he is suggesting to re-use the token endpoint? Tony: Yes. That's what it is anyway. Justin&John: But it is not OAuth protected in the same way since it requires other credentials. John: I don't see too much difference between the current approach of the initial access token, which is an OAuth bearer token, and Phil's proposal other than the type of encoding. John: The client would only present the software assertion and no data by itself? Tony: Yes. John: Would the assertion be signed by a third party or self-signed? Tony: Could be both. Phil: Some JWT that contains a number of claims would work. If someone wanted to use existing set of claims then we have those in OpenID Connect and they would be signed. John: In the current spec the structure of the token is undefined and left to the AS to decide. To have what Tony wants you would need to define the structure of the token in case it is self-signed by the client. Justin: We defined this is in the BlueButton project. We defined various claims and a discovery component (to avoid sending all the claims with every request). We are essentially using software assertions. Justin and John talk about the structure of that token. Tony says that he and Phil is trying to write a document in 4 weeks time that tries to be compatible but some other parts will not be compatible because it replaces existing functionality (e.g., management). Justin: Initially we didn't have the management functionality in there but then added it after some discussion on the OAuth mailing list. The discussion started about the stateless use case. John: There are two aspects: a) do you provide third party attested config info about a client? The info that may be the same for each instance. b) the information you get back could be stateful or stateless in the second step. Phil: I want fewer options. We have to lock it down somewhat. Justin: I am confused about the optionaliality Phil: At the moment there is little there. There is an OAuth token as a bearer token. John: The objection is more related to the options of OAuth. Phil: The different types of apps need different features. For example, mobile apps and Web apps are very different in the flows they need. My use cases as a software api publisher are not solved. John brings up the discussion about the software assertion as a question to Phil in an attempt to define the details. Hannes: We are running out of time; what are the next steps? Justin: we need to describe the use cases and have them written down. Phil: We need two aspects: - - way to express that an authorization server accepts requests from X clients. - - express that a client is a client from X Hannes: Let's not get into the details. We need to find out what the next steps are. Phil: What do you want? slide set, mail to the list, or a draft. Justin: Ideally drafts. Hannes: How much time do you need? Phil+Tony: for a draft a month. Hannes: Will talk to Derek to see how to proceed; in the meanwhile please work on the documents and try to get them finalized as soon as possible. Will also think about future conference calls. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJSIvNjAAoJEGhJURNOOiAtv4cH+wZeSPGH+Iiuetu6v+HY5YZ9 c0OOFT+U9birXEhXxo0T7mnTziUlqGUKOZ7b0cVRH4pCwcJ7Hqvt70NUs7bwMk/Z SAUNj4WnPCI3WKS8IjS9xV7PPD6bRwnWNoJdGHP3p0wZEvD7KWUbdrnhqC9RzVOc 1AvG1SeiM8GIeRzJI1erhVP01so1S1D65z7hBxi2QtsFgjRv+jWSMFjBx1QXH51k RKUvUJG+mqc88JXXl00EvthRD34Goe63GyyhghU9Uwf+KB1aPorI06wfQpyijGhF pK3VVncg5ZmlyKySpB0W9rDbI/Jz9KDrd6+LzCtD4zT71WaMN9h8sCRXCSEiDb0= =i/7t -----END PGP SIGNATURE----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
