Hiya, So I'll take the lack of further discussion about this an meaning that the wg want this to shoot ahead. I'll put this in as an RFC editor note for the draft.
Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > As you have seen on the list (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I had > a chat with Mike about how to address my comment for the assertion draft > and Mike kindly provided his text proposal (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I > have used his text as input and extended it a bit. Here is the updated > text. > > ---- > > Operational Considerations and Interoperability Expectations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework on its own, this specification is > not sufficient to produce interoperable implementations. Two other > specifications that instantiate this framework have been developed, one > uses SAML 2.0-based assertions and is described in > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two > instantiations provide additional details about the assertion encoding > and processing rules for those interested to implement and deploy > assertions with OAuth 2.0. > > However, even with these instance documents an interoperable > implementation is not possible since for a specific deployment > environment (within a trust framework or circle of trust, as it is > sometimes called) agreements about acceptable values for various fields > in the specification have to be agreed upon. For example, the audience > field needs to be populated by the entity that generates the assertion > with a specific value and that value may hold identifiers of different > types (for example, a URL, an IP address, an FQDN) and the entity > receiving and verifying the assertion must compare the value in the > audience field with other information it may obtain from the request > and/or with locally available information. Since the abstract framework > nor the instance documents provide sufficient information about the > syntax, the semantic and the comparison operation of the audience field > additional profiling in further specifications is needed for an > interoperable implementation. This additional profiling is not only > needed for the audience field but also for other fields as well. > > This framework was designed with the expectation that additional > specifications will fill this gap for deployment-specific environments. > > ---- > > You have the choice: > > 1. take this as-is if you want the assertion draft > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is no > normative text in the writeup; it is rather a clarification. > > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on the > Feb 7 > telechat (if the discussion is done by Feb 1) > > 1 or 2 needs to be chosen today. > > > Ciao > Hannes > > PS: FYI - draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer > are not yet on the telechat agenda. > > _______________________________________________ > 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
