Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-saml2-bearer

Brian Campbell <> Fri, 26 August 2011 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7384E21F8C62 for <>; Fri, 26 Aug 2011 09:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.362
X-Spam-Status: No, score=-4.362 tagged_above=-999 required=5 tests=[AWL=-1.585, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2rQQ6F3lVkQH for <>; Fri, 26 Aug 2011 09:08:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4137721F8C15 for <>; Fri, 26 Aug 2011 09:08:31 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 26 Aug 2011 09:09:49 PDT
Received: by with SMTP id 38so547996qyk.5 for <>; Fri, 26 Aug 2011 09:09:41 -0700 (PDT)
Received: by with SMTP id k13mr1709738qcd.214.1314374980200; Fri, 26 Aug 2011 09:09:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Aug 2011 09:09:10 -0700 (PDT)
In-Reply-To: <>
References: <AcxXeAsEDtG02v57TcG9mQtY/vsbFgDySHPA> <>
From: Brian Campbell <>
Date: Fri, 26 Aug 2011 10:09:10 -0600
Message-ID: <>
To: "Engler, Michael" <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "Doersam, Joachim" <>, oauth <>
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-saml2-bearer
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Aug 2011 16:08:33 -0000

Hi Michael,

I apologize for being so slow in responding to this.  I did not
receive the first message and haven't had a chance to respond to this
direct email as I've been very busy trying to get a product release
out the door.  I attempt to answer the questions inline below.  I'm
also cc'ing the OAUTH WG mailing list as these are questions that
others might have too.  Note there are also questions about
draft-ietf-oauth-assertions-00 too.

Thanks for the review and feedback.  Hopefully I can address your questions.

On Mon, Aug 15, 2011 at 5:50 AM, Engler, Michael <> wrote:
> Hi Brian,
> possibly the previous mail was lost somewhere in the IETF mailinglists … thus I send here again directly. I apologize if you now received it twice … J
> Greetings,
> Michael
> _____________________________________________
> From: Engler, Michael
> Sent: Mittwoch, 10. August 2011 18:11
> To: ''
> Cc: Doersam, Joachim
> Subject: Mail regarding draft-ietf-oauth-saml2-bearer
> Hi Brian,
> I are currently reading your latest draft on SAML bearer assertion usage in OAuth 2. Some parts are currently unclear, and it would be great if you could bring light into the dark J …
> In the document I read the following: “If the Assertion was issued with the intention that the presenter act autonomously on behalf of the subject, an <AuthnStatement> SHOULD NOT be included.  The presenter SHOULD be identified in the <NamseID> or similar element, the <SubjectConfirmation> element, or by other available means like [OASIS.saml-deleg-cs].”
> What does it actually mean if the presenter (= OAuth client) acts autonomously but still on behalf of the subject? Isn’t this a contradiction?

Perhaps 'autonomously' isn't the best word there and I'm open to
suggestions on an alternative.  What I'm trying to do is differentiate
between two general cases:  1) the case where the user/resource owner
is present to the client in some way and the client has authenticated
the resource owner or is sufficiently confident in the authentication
event and 2) the case where the client is doing something on behalf of
a resource owner but the resource owner isn't present to the client
and hasn't directly authenticated with the client.   An example of the
former case might be where the client is some web application that the
resource owner has logged onto and is using at the time of this
transaction.  The later case might be where the client is some cron
job or something that runs nightly and does something on the user or
users behalf but without them being around for the transaction.

> Can you elaborate more on this point why the authentication statement should be left out here?

Related to what I said above, there are cases where the resource owner
hasn't authenticated with the client (or some STS) and so it seems
like it makes sense to say that no claim should be made in the
assertion about any type of authentication.  In that case, it's really
just a claim about some identity about whom this access token is being

> Should the SAML subject reference the resource owner, or the OAuth client in that case?

My intent is that the subject (or the subject and some of the
attributes) should reference the resource owner while the delegation
to the client (though it's kind of implied) can be expressed through
other semantics in the assertion (that's what the second sentence from
the piece of the spec you quoted is intended to cover).

> In section 3.1 you write that “If present, the authorization server MUST also validate the client credentials.“ …
> What is the syntax for adding the client credentials to the assertion request in case of the SAML bearer token? Do you refer to the separate assertion covering the client as SAML subject … or are there yet another type of client credentials to take into account?

The means of client authentication is totally independent from the
grant type being presented (true for SAML grant type but also in
general).  That statement is just intended to ensure that client
credentials aren't ignored, if they are there.

> I would assume that the client id needs to be transferred as part of the access token request. In draft-ietf-oauth-assertions-00 you write the following:
> The following non-normative example demonstrates an assertion being
> used as an authorization grant. (line breaks are for display purposes
> only):
> POST /token HTTP/1.1
> Host:
> Content-Type: application/x-www-form-urlencoded
> client_id=s6BhdRkqt3&
> grant_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
> assertion=PHNhbWxwOl...[omitted for brevity]...ZT4
> Why do you assume it is sufficient that the client_id is not contained within the assertion but is “solely” added to the request? In our discussions so far, we assumed that the client id could be transferred as an attribute statement within the SAML assertion. This would prevent tampering with the client id subsequently. What are your thoughts on this?

I don't necessarily assume that in all cases.  In some the client_id
is little more than an identifier (not authentication) of the client -
a hint really.  Other cases might require that the client authenticate
and that can be done any number of ways.  I also think that client_id
should be made optional in the next rev of draft-ietf-oauth-assertion
(it is currently required but that, I think, is an artifact of trying
to stay consistent with a draft of the core spec that is now

> Greetings,
> Michael
> Dr. Michael Engler
> Security & Identity Management
> TIP Core Security, Connectivity, Integration
> Dietmar-Hopp-Allee 16
> 69190 Walldorf
> T   +49/6227/7-47599
> F   +49/6227/78-46187
> E
> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
> Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo Apotheker (stellvertretender Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich, Gerhard Oswald, Peter Zencke
> Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner
> Registergericht/Commercial Register Mannheim No HRB 350269
> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
> Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
> This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.