On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > > Section 5 about "Interoperability Considerations" says: > > " > Specific items that require agreement are as > follows: values for the issuer and audience identifiers, the location > of the token endpoint, and the key used to apply and verify the > digital signature or keyed message digest over the JWT. > " > > I believe that this list is not correct.
The list could probably be expanded to include a mention of how subject is to be identified (related to discussion about subject [1]) as well as requirements the AS may place on upper limits of token expiration and/or de-duping. > What is needed is: > > * At the authorization server there needs to be a whitelist of trusted > issuers. For a succesful protocol run the JWT needs to be created by an > issuer who is in the whitelist. > > * Along with the entry in the whitelist of trusted issuers needs to be a > key. That's one implementation approach. But not the only one. The intent of this section is to note the information which needs to be exchanged/agreed upon in order for the wire protocol to work. That's all. Implementation particulars shouldn't be here. > There is no new endpoint URL defined by this document. As such, I wouldn't > mention those. No but there's been a request, which makes sense, to explicitly state the items which need to be known, typically via service documentation, in order to achieve interoperability. The token endpoint is one of those items and OAuth provides no means of discovering it or publishing it. So I feel it's very appropriate to mention it here. And, by way of example, if you look at service documentation for existing deployments, you'll see that it is included. > I also do not think that the audience identifier needs to be agreed if you > define it as the token endpoint URL of the authorization server (as I > suggested above). As I said in the previous mail on audience [2] and have been arguing/explaining for a long time now, that suggestion is not viable or realistic. And (as I mention above) the token endpoint URL *still* needs to be communicated somehow. Documenting the expected value for audience is just one more piece of information in a set of info that has to be exchanged anyway. [1] sub http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html [2] aud http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
