Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

From: Brian Campbell <[email-masked]>
Date: Thu, 15 Jul 2010 14:50:10 -0600

I'm gong to join the growing list of people attaching a potential I-D
to an email due to he cut off time for the I-D submissions.  Attached
is a draft that aims to tightly define the particular format of a SAML
2.0 bearer assertion in requesting an access token using the assertion
grant_type.   I've been working with Chuck at Salesforce.com on this
and the primary goal is to have some documentation or specification
that is sufficient to facilitate interoperability between
independently developed implementations or products.    This, of
course, wouldn't preclude using SAML in other ways - it would only
provide one concrete definition to implement against.

I intend to submit this as an I-D when the submission process reopens.
  Any feedback from this group would be appreciated as well as
thoughts about this eventually becoming a working group draft.

Thanks,
Brian Campbell

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 18 Jul 2010 17:48:50 +0200

Hi Brian,

thank you for taking the effort to write this I-D.

I have the following remarks:

Why do you prescribe to include the token endpoint URL into the 
SubjectConfirmationData and similar data also in the 
AudienceRestriction? I would expect such data in the AudienceRestriction 
only.

Why do you prohibit NotBefore-Attributes?

What the reason for that statement? "If the assertion was issued with 
the intention that the client act autonomously on behalf of the subject, 
an <AuthnStatement> SHOULD NOT be included." Do you expect the OAuth 
authorization server to authenticate the client anyway?

Your I-D states:
"The authorization server MUST ensure that bearer assertions are
       not replayed, by maintaining the set of used ID values for the
       length of time for which the assertion would be considered valid
       based on the NotOnOrAfter attribute in the
<SubjectConfirmationData>."

Why do you want to force a one-time usage for SAML assertions? This is 
to restrictive, in my opinion. Any issuing authority could enforce such 
a policy by using the "OneTimeUse" element.

2.3.  Error Response: I would suggest to return a 401 status code for 
invalid assertions since I see them as invalid credentials.

regards,
Torsten.

Am 15.07.2010 22:50, schrieb Brian Campbell:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Campbell <[email-masked]>
Date: Sun, 18 Jul 2010 22:34:37 -0600

Torsten,
Thanks for taking the time to review and comment.  I've tried to
address your questions inline below (though in some cases only raising
more questions).

On Sun, Jul 18, 2010 at 9:48 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> SubjectConfirmationData and similar data also in the AudienceRestriction? I
> would expect such data in the AudienceRestriction only.

One of the primary motivators behind much of this document was wanting
to align the assertion format and processing rules as much as was
reasonable with requirements in SAML Web SSO.

The seemingly redundant data in Reciepent of SubjectConfirmationData
and in the AudienceRestriction is very similar to what is required in
Web SSO.  That's the main reason they are both there.

However, there is a subtle distinction between the two -  the
SubjectConfirmationData/Recipient identifies the endpoint to which the
assertion can be delivered (where) and the Audience identifies the
more general entity to whom it can be delivered (who).   In general
practice the two are tightly coupled but they need not necessarily be.

> Why do you prohibit NotBefore-Attributes?

Again trying to follow what was done in Web SSO - the prohibition of
the NotBefore in SubjectConfirmationData was taken directly from
section 4.1.4.2 of saml-profiles-2.0-os.  Honestly, I've never
understood the reason for the restriction and really the reason I had
it here was just to mimic web sso in the hope of facilitating better
reuse of existing software.   Anyway, that was my reasoning but I
woudn't be opposed to removing that language from this document.

Regardless which way we go with that - note that the use of a
NotBefore attribute is allowed in the Conditions element.

> What the reason for that statement? "If the assertion was issued with the
> intention that the client act autonomously on behalf of the subject, an
> <AuthnStatement> SHOULD NOT be included." Do you expect the OAuth

Client authentication to the authorization server is an orthogonal
concern.   This is about the subject of the assertion (which may be
the client but probably won't be in most cases) authenticating with
the issuer of the assertion.

It seems like there are cases where the end user (or subject) is
present during the transaction and will have authenticated directly
with the issuer of the assertion.  But there may also be cases where
the end user is not present and the client is trusted to act on their
behalf.  That bullet and the one before it that says, "If the
assertion issuer authenticated the subject, the assertion SHOULD
contain a single <AuthnStatement> representing that authentication
event" were intended to try and accommodate those two situations and
provide a way to tell the difference based on the content of the
assertion.

It also just seemed like the "right" thing to do - if the issuer
authenticated the subject, say so in the assertion.  If not, say
nothing about it in the assertion.

> Why do you want to force a one-time usage for SAML assertions?
> This is to  restrictive, in my opinion.

This is also a carryover from web SSO via the POST binding.  I was
actually leaning towards not including this language but a couple
early reviews were interesting in having it in there.  My co-author on
this draft, Mr. Chuck Mortimore, was one of those folks so maybe he
could provide more insight into his reasoning there.  Chuck?

> Any issuing authority could enforce such a
> policy by using the "OneTimeUse" element.

Personally, I've always found the spec language around OneTimeUse to
be confusing and somewhat ambiguous.   Maybe I'm wrong but take a look
at "2.5.1.5 Element <OneTimeUse>" and the treatment of OneTimeUse in
"2.5.1 Element <Conditions>" of saml-core-2.0-os.  There are parts of
that language that do suggest OneTimeUse is intended to indicate that
some replay check is required but other parts seem to say something
entirely different.   I don't believe that OneTimeUse is widely used
or supported.

> invalid assertions since I see them as invalid credentials.

That's a good point.  I had 400 largely as a copy/paste error from
another example.  However, as I take a closer look at the text in
draft -10 of the core OAuth spec, it would seem that it prescribes a
400 for this case.   Section "4.3. Error Response" says,

  "If the client provided invalid credentials using an HTTP
   authentication scheme via the "Authorization" request header field,
   the authorization server MUST respond with the HTTP 401
   (Unauthorized) status code.  Otherwise, the authorization server
   SHALL respond with the HTTP 400 (Bad Request) status code."
   -- http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.3

Now I'm not sure which makes sense.  Is it really an HTTP
Unauthorized?  It's not an HTTP authentication that is failing but
rather a higher level protocol.   Maybe this is a question to be
addressed at the core spec level?

I might just drop the example I have in section 2.3 of this document
and defer completed to the core spec :)

-Brian

BTW, I referenced the SAML specs a few times in this email and should
say that http://saml.xml.org/saml-specifications is a nice place to
find all the OASIS SAML specs, including the latest errata, in one
place.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 22 Jul 2010 23:39:50 +0200

> reasonable with requirements in SAML Web SSO.

Sounds like you defining a profile of the OAuth assertion flow for using 
SAML assertions complying to the SAML "Web Browser SSO Profile". I think 
you should state that somewhere. There will probably be other assertion 
flow profiles for other SAML assertion "dialects".

> NotBefore attribute is allowed in the Conditions element.

ok, seems I mixed both attributes up. The conditions element is more 
important.

> contain a single<AuthnStatement>  representing that authentication

understood.

> at "2.5.1.5 Element<OneTimeUse>" and the treatment of OneTimeUse in
> "2.5.1 Element<Conditions>" of saml-core-2.0-os.  There are parts of

We don't use it, too :-)

> addressed at the core spec level?

You are right, status code 401 is used in case of invalid client 
credentials. An invalid assertion is an error on a higher protocol level.

> find all the OASIS SAML specs, including the latest errata, in one

Thank you for this hint, I'm more (SAML Core) or less (Profiles) 
familiar with the specs.

regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 27 Jul 2010 10:48:48 -0600

On Thu, Jul 22, 2010 at 3:39 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> SAML assertions complying to the SAML "Web Browser SSO Profile". I think you
> should state that somewhere. There will probably be other assertion flow
> profiles for other SAML assertion "dialects".

It's not *exactly* like the the Web SSO Profile but similar in most
respects.  I'll work in some language about that intent in the next
draft.

>> entirely different.   I don't believe that OneTimeUse is widely used

:)
Anyone else have thoughts on the "not replayed" clause in here?  I'm
on the fence about it, as I said.  Chuck, I know your busy conference
hopping but if you get a chance, can you describe again why you
thought this was important?

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 27 Jul 2010 11:26:55 -0700

Yes - this is intended to be a simplified parallel to web sso profile.  We also intend to ship a straight adaptation of websso, as do others I believe

For both of these, We intend to enforce one time use; I suspect that type of state maintenance will get argued against by those running the large scale consumer systems...it's manageable for us given how our Multi-tenancy is setup.  I could see relaxing this to a should if people feel strongly.  It would be good to see some arguments/use-cases along with the objections

I would also like to see other profiles, such as a holder of key profile.  This is a good starting point for what our customers need /request, but we intend to expand profiles as customers and the industry evolve

- cmort

---

From: Brian Campbell <[email-masked]>
Date: Tue, 27 Jul 2010 12:56:06 -0600

On Tue, Jul 27, 2010 at 12:26 PM, Chuck Mortimore
<[email-masked]> wrote:
> For both of these, We intend to enforce one time use; I suspect that type of state maintenance will get argued against by those running the large
> scale consumer systems...it's manageable for us given how our Multi-tenancy is setup.  I could see relaxing this to a should if people feel strongly.
> It would be good to see some arguments/use-cases along with the objections

There seem to be two potential arguments against it - the burden of
tracking the state and the potential that it's unnecessarily
restrictive.  I don't personally see either as being a major issue but
would like to hear from folks if they feel differently.   I could
change the language from a MUST to a SHOULD or MAY to allow for more
flexibility at deployment/development time?  That would slightly
increase the opportunity for interop problems but I don't think it's
really much of a concern.

I don't really want to rely on the OneTimeUse condition for the
reasons I mentioned previously as well as the fact that it seems to me
to be a decision of the assertion consumer just as much as (or more
than) it is of the assertion issuer.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 27 Jul 2010 16:40:50 -0700

> really much of a concern.

MAY seems reasonable to me.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 28 Jul 2010 08:41:45 +0200

> MAY seems reasonable to me.

+1

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 28 Jul 2010 06:06:24 -0400

+1 on MAY;  (+0.3 on SHOULD).

Igor

---

From: Brian Campbell <[email-masked]>
Date: Wed, 28 Jul 2010 05:02:09 -0600

MAY it is.  Thanks

On Jul 28, 2010 4:06 AM, "Igor Faynberg" <[email-masked]>
wrote:

Igor

Torsten Lodderstedt wrote:
>...