IETF Logo Mail Archive

Re: [OAUTH-WG] audience (was draft-ietf-oauth-saml2-bearer-17)

Chuck Mortimore <cmortimore@salesforce.com> Wed, 06 November 2013 05:19 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 EC17A21E80B5 for <oauth@ietfa.amsl.com>; Tue, 5 Nov 2013 21:19:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV8FMRcqK1aN for <oauth@ietfa.amsl.com>; Tue, 5 Nov 2013 21:19:26 -0800 (PST)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAC721E80BF for <oauth@ietf.org>; Tue, 5 Nov 2013 21:19:23 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id wn1so9643757obc.16 for <oauth@ietf.org>; Tue, 05 Nov 2013 21:19:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XN9IaOZDTqba6VD+PVUb7dHt2sO4EvTQRqrViWliLwA=; b=JQDxJuJL6CoCiQ6Jrza0JqT1qP56qPF79URjRK3h1HqnPIwW9wzNnvI528bbJ0C6lv 7fDJJl7Q+d0SV+N3aldk/6OU7MdCLjCwm1AuX3sbB6hj1reTwB4ff7g0GCOclLD1wU3P WL+9TmPoLGSHGXzsoDkLvzoNeHcrtS5TpdevBSl/ZKIHsc3rEdBS1CfQ+qX6SUGiqYDD 2dx9l/W4ytwdcoZmJ1wlEYxLqKsTcHM/vieVryLfGAi8KCQSm+MPh/64Cb/tUn+sB14c TfVM5Hd2buRAFN79ObJ6a7JGlyR71Wz/Phn8p7u7qDPupSsGVIpYNYsL7Y7IYpHz7cAy DHTQ==
X-Gm-Message-State: ALoCoQk184HZi4KvpZbEPAOOtwNuDPK+yIGmPoCB2ILsycQOhU/kZgGD7ko9TrhU8VCxV5/2USSr
MIME-Version: 1.0
X-Received: by 10.60.44.178 with SMTP id f18mr1097845oem.43.1383715163280; Tue, 05 Nov 2013 21:19:23 -0800 (PST)
Received: by 10.76.24.162 with HTTP; Tue, 5 Nov 2013 21:19:23 -0800 (PST)
In-Reply-To: <CA+k3eCRu4v=++_OcC2PzMbKRdcH6fV0Rb0F6Lgpu5oJ8a6g-Rg@mail.gmail.com>
References: <CA+k3eCRu4v=++_OcC2PzMbKRdcH6fV0Rb0F6Lgpu5oJ8a6g-Rg@mail.gmail.com>
Date: Tue, 05 Nov 2013 21:19:23 -0800
Message-ID: <CA+wnMn_S5_6PfwKLJBDhNUnwy7sGyoknrVfHQ_+KDH_3fN9a3A@mail.gmail.com>
From: Chuck Mortimore <cmortimore@salesforce.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary="001a11333a4ec7209404ea7b4abb"
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] audience (was draft-ietf-oauth-saml2-bearer-17)
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: Wed, 06 Nov 2013 05:19:31 -0000

On Mon, Nov 4, 2013 at 11:58 AM, Brian Campbell
<bcampbell@pingidentity.com>wrote:

> On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net> wrote
> > Item #2: You wrote:
> >
> > "
> > Section 2.5.1.4 of Assertions and Protocols for the OASIS
> >         Security Assertion Markup Language [OASIS.saml-core-2.0-os]
> >         defines the <AudienceRestriction> and <Audience> elements and,
> >         in addition to the URI references discussed there, the token
> >         endpoint URL of the authorization server MAY be used as a URI
> >         that identifies the authorization server as an intended
> >         audience.  Assertions that do not identify the Authorization
> >         Server as an intended audience MUST be rejected.
> > "
> >
> > The 'MAY' is extremely weak here. If you make it a MUST that there has
> to be
> > the endpoint URL of the authorization server in there then that would
> > provide so much more interoperability. As a reader I wouldn't know what
> > other options I have and systems that provision necessary databases /
> tables
> > to ensure that the comparison takes place will also struggle.
>
> The "MAY" is intended to be weak and is only a suggestion for
> deployments which don't already have a suitable identifier (like a
> SAML 2 entity ID) for an audience value.
>
> I understand that you'd like this to be tighter but the suggestion is
> not viable and it wouldn't provide the perceived interoperability
> panacea anyway. Some information needs to be agreed upon for this to
> work. How is out of scope here. The audience is one such value. Even
> if mandating one specific thing for audience was feasible, it wouldn't
> add to interoperability because there is other information that has to
> be agreed on anyway.
>
>
> > Then, there is again this SHOULD regarding the comparison operation, see
> > "
> >  Audience
> >         values SHOULD be compared using the Simple String Comparison
> >         method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
> >         otherwise specified by the application.
> > "
> >
> > I would replace it with a MUST, as I argued in
> > draft-ietf-oauth-jwt-bearer-06.
>
> As I said there [1], I think I'm okay with that but would like to hear
> from others in the WG.
>

I'm ok with that as well.



>
> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

v2.23.0 | Report a Bug | By Email