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
