I apologize for not participating in much of the discussion around this - I've been otherwise occupied this week with a myriad of other priorities at work.
I would, however, like to voice my support in favor of the version of the text that Mike proposed. On Fri, Jan 18, 2013 at 3:59 PM, Mike Jones <michael.jo...@microsoft.com>wrote: > To make the proposed changes concrete, I've made them in a proposed draft > 10 (attached). This contains no normative changes from draft 9. People > should look at Section 1.1 (Interoperability Considerations) and review the > new text there. The only other change was renaming "Principal" to > "Subject" to align terminology with the SAML and JWT specs, as discussed on > the list. > > I will wait for OK from one of the chairs or Stephen before checking this > in. > > -- Mike > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Mike Jones > Sent: Friday, January 18, 2013 2:31 PM > To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- > Today > > I can't agree with proceeding with Hannes' rewrite of the interoperability > text, as editorially, it reads like it is apologizing for a defect in the > specification, whereas it is an intentional feature of the specification > that the syntax and verification rules of some fields is intentionally left > open for profiles to specify (even while the semantics of them is defined > by the Assertions spec). I propose that instead, we go with the revised > version at the end of this message, which I believe incorporates Hannes' > ideas while keeping the editorial tone positive. > > Second, I believe that we should proceed with the non-normative > terminology change of "Principal" to "Subject", which was proposed in > http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and > supported by Justin and Torsten, with no one opposed. This should go into > the version being discussed on the telechat (as well as the > interoperability text). > > Finally, I believe that it would be beneficial to all to have the > Assertions and SAML Profile specs be discussed on the same telechat, as > both are useful for understanding the other. Frankly, I think they should > go to the IETF Editor together as "related specifications", with the goal > being consecutively numbered RFCs referencing one another. Is there any > reason we can't schedule both for the February 7th telechat? (I don't > actually understand how they failed to proceed in lock-step in the first > place. Chairs - any insights?) > > ==== > > Interoperability Considerations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework in which the data formats used for > representing many values are not defined, on its own, this specification is > not sufficient to produce interoperable implementations. > > Two other specifications that profile this framework for specific > assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses > SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses > JSON Web Tokens (JWTs). These two instantiations of this framework specify > additional details about the assertion encoding and processing rules for > using those kinds of assertions with OAuth 2.0. > > However, even when profiled for specific assertion types, additional > profiling for specific use cases will be required to achieve full > interoperability. Deployments for particular trust frameworks, circles of > trust, or other uses cases will need to agree among the participants on the > kinds of values to be used for some abstract fields defined by this > specification. For example the values of Issuer, Subject, and Audience > fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, > IP addresses, or other values, depending upon the requirements of the > particular use case. The verification rules for some values will also be > use case specific. > > This framework was designed with the clear expectation that additional > specifications will define prescriptive profiles and extensions necessary > to achieve full web-scale interoperability for particular use cases. > > ==== > > Thanks all, > -- Mike > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- > Today > > > 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 > _______________________________________________ > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
