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

John Bradley <ve7jtb@ve7jtb.com> Sat, 19 January 2013 01:33 UTC

Return-Path: <ve7jtb@ve7jtb.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 DFDF921F84F8 for <oauth@ietfa.amsl.com>; Fri, 18 Jan 2013 17:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 PggoDVQv2nnf for <oauth@ietfa.amsl.com>; Fri, 18 Jan 2013 17:33:35 -0800 (PST)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id C19AD21F84F2 for <oauth@ietf.org>; Fri, 18 Jan 2013 17:33:35 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id k10so7295442iea.29 for <oauth@ietf.org>; Fri, 18 Jan 2013 17:33:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=M1YzLwMuHiwHoaLmoOhmchG9O6hqE2qS7B2Nv7FmdWE=; b=Z1YGjHLx2kGgQpWTCNZ7lYjnv5dkyCHcWoXC09XWtklJaS+lYv6nDjdzKb6hQOTXQg IXO0VMZgfgxYR9BmNgF9TGP2tljCHl+k9aFyTcrvLJiQ3kNKs0HXx/n/R/EBgk2VNNdc k7WxRtyj047+Sr8SGAtmzq4addFRssSKM8UfigxVYXR9beOkn1pfE4XrRiwhlJDsaX2u F+4zy3eR7mZkoS2RrTVtAabxuKDQMeTOwe3yrhKECF9KylDgHxai/o1fT3pmd9G4iUuJ fA6Kfb7dYOl1hmWrtw2QFi0E3kSur58absfuGm1MD/teZEoZr+ZIvw1ZJEy9bqAu56zy i83A==
X-Received: by 10.50.89.165 with SMTP id bp5mr3688076igb.70.1358559215322; Fri, 18 Jan 2013 17:33:35 -0800 (PST)
Received: from [10.111.113.32] ([38.109.210.2]) by mx.google.com with ESMTPS id dc8sm3437365igb.15.2013.01.18.17.33.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 17:33:34 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Fri, 18 Jan 2013 18:33:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B0E60D3-A9CC-44F2-B588-CAFBA0B56746@ve7jtb.com>
References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm6WNNMSWvvJVDPCYGGdN269tyb2sWj85eaSxqNvSWrI7kb6mexpMRacPbSg/JMvXscZKpX
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 01:33:37 -0000

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.
On 2013-01-18, at 3:30 PM, Mike Jones <Michael.Jones@microsoft.com> 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.
> 
> 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] 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