From: Mike Jones <Michael.Jones@microsoft.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Tschofenig,
 Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Thread-Topic: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Thread-Index: Ac31c/ey/0oPxcEZTU2GjVm1VBYpaAAL9XQAAAkriSA=
Date: Fri, 18 Jan 2013 22:30:55 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net>
 <50F98A8E.7090701@cs.tcd.ie>
In-Reply-To: <50F98A8E.7090701@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Precedence: 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 s=
pecification, whereas it is an intentional feature of the specification tha=
t the syntax and verification rules of some fields is intentionally left op=
en 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 versi=
on at the end of this message, which I believe incorporates Hannes' ideas w=
hile 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 an=
d Torsten, with no one opposed.  This should go into the version being disc=
ussed on the telechat (as well as the interoperability text).

Finally, I believe that it would be beneficial to all to have the Assertion=
s and SAML Profile specs be discussed on the same telechat, as both are use=
ful for understanding the other.  Frankly, I think they should go to the IE=
TF Editor together as "related specifications", with the goal being consecu=
tively 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?)

=3D=3D=3D=3D

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 repre=
senting many values are not defined, on its own, this specification is not =
sufficient to produce interoperable implementations.=20

Two other specifications that profile this framework for specific assertion=
 have been developed:  one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-ba=
sed assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web To=
kens (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 profil=
ing for specific use cases will be required to achieve full interoperabilit=
y.  Deployments for particular trust frameworks, circles of trust, or other=
 uses cases will need to agree among the participants on the kinds of value=
s to be used for some abstract fields defined by this specification.  For e=
xample the values of Issuer, Subject, and Audience fields might be URLs, UR=
Is, fully qualified domain names, OAuth client IDs, IP addresses, or other =
values, depending upon the requirements of the particular use case.  The ve=
rification rules for some values will also be use case specific.

This framework was designed with the clear expectation that additional spec=
ifications will define prescriptive profiles and extensions necessary to ac=
hieve full web-scale interoperability for particular use cases.

=3D=3D=3D=3D

				Thanks all,
				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S=
tephen 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 -- Tod=
ay


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,
>=20
> As you have seen on the list (see
> http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I=20
> had a chat with Mike about how to address my comment for the assertion=20
> draft and Mike kindly provided his text proposal (see=20
> http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I=20
> have used his text as input and extended it a bit. Here is the updated=20
> text.
>=20
> ----
>=20
> Operational Considerations and Interoperability Expectations
>=20
> This specification defines a framework for using assertions with OAuth=20
> 2.0. However, as an abstract framework on its own, this specification=20
> is not sufficient to produce interoperable implementations. Two other=20
> specifications that instantiate this framework have been developed,=20
> one uses SAML 2.0-based assertions and is described in=20
> [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=20
> instantiations provide additional details about the assertion encoding=20
> and processing rules for those interested to implement and deploy=20
> assertions with OAuth 2.0.
>=20
> However, even with these instance documents an interoperable=20
> implementation is not possible since for a specific deployment=20
> environment (within a trust framework or circle of trust, as it is=20
> sometimes called) agreements about acceptable values for various=20
> fields in the specification have to be agreed upon. For example, the=20
> audience field needs to be populated by the entity that generates the=20
> assertion with a specific value and that value may hold identifiers of=20
> different types (for example, a URL, an IP address, an FQDN) and the=20
> entity receiving and verifying the assertion must compare the value in=20
> the audience field with other information it may obtain from the=20
> request and/or with locally available information. Since the abstract=20
> framework nor the instance documents provide sufficient information=20
> about the syntax, the semantic and the comparison operation of the=20
> audience field additional profiling in further specifications is=20
> needed for an interoperable implementation. This additional profiling=20
> is not only needed for the audience field but also for other fields as we=
ll.
>=20
> This framework was designed with the expectation that additional=20
> specifications will fill this gap for deployment-specific environments.
>=20
> ----
>=20
> You have the choice:
>=20
> 1. take this as-is if you want the assertion draft=20
> (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is=20
> no normative text in the writeup; it is rather a clarification.
>=20
> 2. discuss it if need be, and draft-ietf-oauth-assertions will be on=20
> the Feb 7
>    telechat (if the discussion is done by Feb 1)
>=20
> 1 or 2 needs to be chosen today.
>=20
>=20
> Ciao
> Hannes
>=20
> PS: FYI - draft-ietf-oauth-saml2-bearer and=20
> draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth