Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

[Mike Jones <[e-mail]>]

When can we get the IESG to review the SAML Assertions draft?  It would be good to get the Assertions draft and the SAML Assertions draft back in sync, from a schedule and process perspective, as comments on one may also reflect on the other.

				-- Mike

-----Original Message-----
From: Hannes Tschofenig [mailto:[e-mail]] 
Sent: Saturday, January 19, 2013 8:19 AM
To: Mike Jones
Cc: Hannes Tschofenig; Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

Hi Mike, Hi all, 

Thanks for the feedback. I see that a couple of you have decided to go with option 2.

Regarding the comments below. 

On Jan 19, 2013, at 12:30 AM, Mike Jones wrote:

> 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.

I tried to provide an honest assessment of the situation with my writeup. 

> 
> 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).

It would certainly make sense to re-submit a new version with this change and then we see how it reads. Now, since we have a bit more time that should not be an issue at all. 

> 
> 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?)

It might be beneficial to have the two discussed together but the IESG has not done the reviews of the SAML assertion draft yet and therefore it is not on the agenda yet. 

Ciao
Hannes

> 
> ====
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Stephen Farrell
> Sent: Friday, January 18, 2013 9:47 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [e-mail]
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth