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

Chuck Mortimore <cmortimore@salesforce.com> Sat, 19 January 2013 00:39 UTC

Return-Path: <cmortimore@salesforce.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E707F21F86D2 for <oauth@ietfa.amsl.com>; Fri, 18 Jan 2013 16:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shhdZuwcrr43 for <oauth@ietfa.amsl.com>; Fri, 18 Jan 2013 16:39:43 -0800 (PST)
Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by ietfa.amsl.com (Postfix) with SMTP id 82A4021F869C for <oauth@ietf.org>; Fri, 18 Jan 2013 16:39:28 -0800 (PST)
Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKUPnrQPmwwweYaWAsFfnrELpWFwv1S7jS@postini.com; Fri, 18 Jan 2013 16:39:28 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Fri, 18 Jan 2013 16:39:28 -0800
From: Chuck Mortimore <cmortimore@salesforce.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 18 Jan 2013 16:39:27 -0800
Thread-Topic: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Thread-Index: Ac313W+b07WcaXplTXCnqorjTxcHCw==
Message-ID: <29D9514D-88ED-4433-BC48-58B08BB37716@salesforce.com>
References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366A50570@TK5EX14MBXC284.redmond.corp.microsoft.com> <CA+k3eCQuG-fGiZOWdgBUfnA5jOMu-iM=8VntdQxAbr8dXQp72A@mail.gmail.com>
In-Reply-To: <CA+k3eCQuG-fGiZOWdgBUfnA5jOMu-iM=8VntdQxAbr8dXQp72A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_29D9514D88ED4433BC4858B08BB37716salesforcecom_"
MIME-Version: 1.0
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Jan 2013 00:39:45 -0000

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 <Michael.Jones@microsoft.com<mailto:Michael.Jones@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-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org<mailto:oauth-bounces@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<mailto: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-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org<mailto:oauth-bounces@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<mailto: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<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth