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

Brian Campbell <bcampbell@pingidentity.com> Fri, 18 January 2013 23:33 UTC

Return-Path: <bcampbell@pingidentity.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 7309321F85AC for <oauth@ietfa.amsl.com>; Fri, 18 Jan 2013 15:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.826
X-Spam-Level:
X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 i1m8J42HfwMz for <oauth@ietfa.amsl.com>; Fri, 18 Jan 2013 15:33:15 -0800 (PST)
Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id A21DC21F856D for <oauth@ietf.org>; Fri, 18 Jan 2013 15:33:14 -0800 (PST)
Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUPnbuvBCAO8hm5DsTxolW92QMo1S2O/P@postini.com; Fri, 18 Jan 2013 15:33:14 PST
Received: by mail-oa0-f71.google.com with SMTP id n12so20757673oag.6 for <oauth@ietf.org>; Fri, 18 Jan 2013 15:33:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=gP1xf6+sfnLM8CL4NFuG0rBUUKSaNUp33fM9gt2k3LQ=; b=oAqEAqx0S7C8wHeehAbyHHZadbz5xLigbqxFFPmmX5gzHWBhva0Rb4q9FcVLfXQGyk RiGxOwNOvHsvgjBM2imfDlk7Gc1Q/DjiNz78sz9FNfx413UCIkBT08q/27uBNKtPE6d4 H2HVc1VV8++ZpWWEmEtIvMz/RqF8jjn+1/ZeTYm2GtCj85CdiC5HxmxRxCX1ewXXSq58 YhckYY3ZPqhxt/7o0eZNmqQHKVACYV7YOEj49o0ZGz8vF1ZAZDeNThyYa2f7VqMWoUZh Vn1vy8XIFxEliwLC1dnWRkpDZk1AHe7a0U+ELiLBrvKjIpXbkReg4tZL2+lS/52gS8D/ UZ9g==
X-Received: by 10.50.161.232 with SMTP id xv8mr3491063igb.22.1358551993779; Fri, 18 Jan 2013 15:33:13 -0800 (PST)
X-Received: by 10.50.161.232 with SMTP id xv8mr3491060igb.22.1358551993676; Fri, 18 Jan 2013 15:33:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.17.134 with HTTP; Fri, 18 Jan 2013 15:32:43 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A50570@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366A50570@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 18 Jan 2013 16:32:43 -0700
Message-ID: <CA+k3eCQuG-fGiZOWdgBUfnA5jOMu-iM=8VntdQxAbr8dXQp72A@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=14dae93409a9fdf54a04d398887a
X-Gm-Message-State: ALoCoQlR+qs8kL/44T/pM4nVy0ZF/U3BU/yPK0XUeh4VyKRmvwXonqvzV2fjj8Kcdk0WZYYQrbOz4DcRB5XmixJ5J+seWMRSuvpe/HZI0l/QunKpIzojiQaC9Y2gvicHvP2/9yMHBJkE
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: Fri, 18 Jan 2013 23:33:16 -0000

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