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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Jan 2013 14:04:28 +0200

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.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Jan 2013 17:46:54 +0000

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:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
> 
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 18 Jan 2013 22:30:55 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, January 18, 2013 9:47 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]
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:
> 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 
> 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 
> 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.
> 
> (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
> PS: FYI - draft-ietf-oauth-saml2-bearer and 
> draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda.
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 18 Jan 2013 22:59:30 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, January 18, 2013 2:31 PM
To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

====

====

				Thanks all,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, January 18, 2013 9:47 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

Hiya,

Cheers,
S.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 18 Jan 2013 16:32:43 -0700

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 <[email-masked]>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 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?)
>
> ====
>
> 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
>
> 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.
>

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 18 Jan 2013 16:39:27 -0800

Same comment as Brian.    I support Mike's proposed text.

-cmort

On Jan 18, 2013, at 3:32 PM, Brian Campbell wrote:

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 <[email-masked]<mailto:[email-masked]>> 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.

                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Friday, January 18, 2013 2:31 PM
To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

====

====

                                Thanks all,
                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stephen Farrell
Sent: Friday, January 18, 2013 9:47 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

Hiya,

Cheers,
S.

On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Jan 2013 18:33:33 -0700

I prefer Mike's wording over Hannes's rewrite.  

This is a design feature to leave it to specs like openID Connect to profile what the values are.  We did that in the context of what made sense for the spec using the assertion profile.

I thought I also supported changing Principal to Subject on this list but it could have been one of the other places, that I agreed to the change:)

John B.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 19 Jan 2013 18:19:03 +0200

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. 

> 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 feat…

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

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 th…

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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 19 Jan 2013 16:36:50 +0000

Hi Hannes,

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

Yep, looks like it. I've moved this back to Feb 7 so the
discussion doesn't need to be rushed.

S.

---

From: Mike Jones <[email-masked]>
Date: Sat, 19 Jan 2013 20:17:47 +0000

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:[email-masked]] 
Sent: Saturday, January 19, 2013 8:19 AM
To: Mike Jones
Cc: Hannes Tschofenig; Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

Hi Mike, Hi all, 

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

Ciao
Hannes

>> had a chat with Mike about how to address my comment for the 
>> assertion draft and Mike kindly provided his text proposal (see 
>> have used his text as input and extended it a bit. Here is the 
>> updated text.
>> 
>> ----
>> 
>> 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
>> instantiations provide additional details about the assertion 
>> encoding and processing rules for those interested to implement and 
>> deploy assertions with OAuth 2.0.
>> 
>> 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.
>>