Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03

Brian Campbell <bcampbell@pingidentity.com> Thu, 28 June 2012 22:57 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 4A10721F84DA for <oauth@ietfa.amsl.com>; Thu, 28 Jun 2012 15:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.988
X-Spam-Level:
X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 VjHeOZGSChsS for <oauth@ietfa.amsl.com>; Thu, 28 Jun 2012 15:57:40 -0700 (PDT)
Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0A521F84D3 for <oauth@ietf.org>; Thu, 28 Jun 2012 15:57:39 -0700 (PDT)
Received: from mail-vc0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKT+zhYirvDm2bZBFzXIl4zUKCA4oaSqtf@postini.com; Thu, 28 Jun 2012 15:57:39 PDT
Received: by vcbgb22 with SMTP id gb22so2206638vcb.29 for <oauth@ietf.org>; Thu, 28 Jun 2012 15:57:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=KtiUngnk1b8eudPFfcx+wTrTH8zjt8FhtIIX0ENFPsk=; b=OfmuLWYgZoEhMkB9spDOoaNSwXOZ9kFfiDb9IC0CHgbPlVa9vX7gnXDdczKlBIwcAz 5xZWif9MlSRPTcketyb4f1GZ9H/qGxK0gvOnnZbPqqlwR/aYUFY76zcLxaEU3Qtr3nha MLJYXfdQtc58tPHGvAxeDjBYVtp/Q4DYsk+Cy4e2H18JuSCQVpkQtRAcg6wl6YRG9sxQ cLmUcyyoYbIny7MjS3w4xFGHrWNV2I80giat0qmPrEHX1M3uCvveNpWbzzpjnisNvB0D jGtATuoWH+vZe0asKwL0EHb2yulUYGOM5cxqbshy7DU8iUIUQxddLWVM7nIG2nAOVEsT VUtg==
Received: by 10.52.156.47 with SMTP id wb15mr2484324vdb.53.1340924258232; Thu, 28 Jun 2012 15:57:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.34.107 with HTTP; Thu, 28 Jun 2012 15:57:07 -0700 (PDT)
In-Reply-To: <12F7B6DB-A371-4C53-8B5B-B34F3750E507@gmx.net>
References: <699C916A-F8B1-40E8-8C3B-FCC9CBCC2C9F@gmx.net> <CA+k3eCQUdc1Mgm6Dd9zMTbPaKuiqntHUKM2ai=hfVWJJ7J9wCA@mail.gmail.com> <12F7B6DB-A371-4C53-8B5B-B34F3750E507@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 28 Jun 2012 16:57:07 -0600
Message-ID: <CA+k3eCQkSkHW104=08H_8sJFNr0SjittBLcYHtYxJB04zJRqPA@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="bcaec53aef5815291304c390424f"
X-Gm-Message-State: ALoCoQlHiLZUj3wMpqG3jJUPNNEWIhuDlVIc2Wt7VU7P2ebLplBSG5c71+8X2zYYIcGD1ZmXqPBb
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03
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: Thu, 28 Jun 2012 22:57:41 -0000

Hi Hannes,

Near the end of §1 of your draft -04 you discuss client authentication with
the Resource Server by saying that the client authentication concerns steps
(E) and (F) in figure 1. However, my reading of §2.3 of the core OAuth
Framework[1] was that only client authentication to the AS was in scope for
the spec. Following from that, my assumption and intent with the assertion
spec was that client assertion authentication is only defined for a client
authenticating to the token endpoint of an AS. §3 of the -03 of the
assertions doc[2] even says, "This specification provides a model for using
assertions for authentication of an OAuth client during interactions with
an Authorization Server".

Was there something in the -03 draft (or the core spec for that matter)
that suggested it was intended for client to RS authentication? I don't
think specifying that (other than in defining how an access token is
presented like draft-ietf-oauth-v2-bearer does) that would be appropriate.
Maybe some clarification is needed?

Thanks,
Brian

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-2.3
[2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-3

On Sun, Jun 24, 2012 at 7:42 AM, Hannes Tschofenig <
Hannes.Tschofenig@gmx.net> wrote:

> Hi Brian,
>
> thanks for your response. I have tried to put additional text into version
> -04 of the draft to address my earlier comments.
>
> The most recent version of the updated document is there:
>
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.txt
>
> Here is the XML:
>
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.xml
>
> It took me a little while to make these changes, as you can imagine. I
> hope I was able to improve the quality and clarity of the document.
>
> I still have to respond to your second mail about the relaxed usage of the
> RFC 2119 language. Will do that asap.
>
> Ciao
> Hannes
>
>