Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 16 Oct 2014 04:20:32 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- intro para2: might be nice (no more) to add some refs to
other protocols that use SAML. 

- 2.2: What are "padding bits" in 4648? I don't recall such.
(But may be misremembering.)

- section 3, list item 2: This doesn't quite say that the
token endpoint URL MUST (in the absence of another profile) be
in an Audience element. Why not? The text seems to me to allow
for the AS to map the token endpoint URL to any value in an
Audience element that the AS finds ok. I suspect that might be
unwise, but it at least needs to be clear. Is that the text
being ambiguous or me being paranoid/wrong? Same point seems
to apply elsewhere too: 
   = in item 3.A where it says "typically identifies" but
   does not say how. 
   = in item 5 "or an acceptable alias"

- section 3, item 7: How might an AS know that "the Assertion
was issued with the intention that the client act autonomously
on behalf of the subject"?

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Oct 2014 13:28:50 -0600

Thanks for your review and feedback, Stephen. Replies are inline below...

> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/

OK

> (But may be misremembering.)

 FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd)
so, trusting in him, I just took the text without question.

But I believe it means and is basically just restating what is said near
the middle/end of §4 in 4648, "When fewer than 24 input  bits are available
in an input group, bits with value zero are added (on the right) to form an
integral number of 6-bit groups." -
https://tools.ietf.org/html/rfc4648#section-4

Are you saying Peter is wrong? ;)

> being ambiguous or me being paranoid/wrong?

You are not wrong. But it's intentionally that way to allow for how this
will actually be used and deployed (and currently is). It accommodates how
SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as
well as providing the token endpoint URL as a means of identifying the AS
as an audience for deployments that wouldn't otherwise have a SAML 2.0
entity id to use.

This profile is just a small piece of a bigger picture and, as such, needs
to fit into the larger picture. Oftentimes it will be deployed as a
complement to existing SAML deployments where trust has already been
established and keys and identifiers have already been exchanged, in which
case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that
context should be used as the audience. But I couldn't presume that would
always be the case so needed to provide some guidance for what to use as
the audience in the absence of a larger SAML deployment. OAuth doesn't have
any kind of discovery or metadata, only endpoints to identify an AS, and
this draft isn't going to address that. So the token endpoint is really the
only option.

I understand the desire to have something neat and tidy here but it's just
not feasible to do so and reconcile with the way this kind of software is
actually deployed and used.

Some stuff needs to be exchanged out-of-band for this to work.
Entity/issuer/audience identifiers are part of that. This need is discussed
in the Interoperability Considerations at
https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5

> Same point seems

Could be an email, a username, a guid, a distinguished name, a certificate,
a persistent pseudonymous id, a transient pseudonymous id, etc.

Like all cross domain identity systems, part of the deployment is
determining how identities will be conveyed. Nailing that down any more is
way beyond the scope of this draft. It's also mentioned in the
Interoperability Considerations.
https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5

>    = in item 5 "or an acceptable alias"

To give the AS some flexibility in what it accepts as identifying itself.

> on behalf of the subject"?
Item 7 is intended to provide a way to single that to the AS - and it's
really about if the user directly authenticated or not. The issuer of the
assertion will know (usually) if the user authenticated directly or if the
assertion is being issued about the subject based on some other trust
relationship with the client.

The same section was discussed in Pete Resnick's review, near the end of
http://www.ietf.org/mail-archive/web/oauth/current/msg13599.html with the
suggestion of saying "directly authenticated" in the first sentence to be
more clear about it. But I'm open to additional clarification, if you have
a suggestion.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Oct 2014 21:54:20 +0100

Hiya,

Mostly fine just a couple of notes.

> Are you saying Peter is wrong? ;)

Heh.

> https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5

So I think it'd be good to explicitly call out that these
mappings are basically required and that they can be fraught
(e.g. if someone uses wildcards badly, which they do).

Cheers,
S.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Oct 2014 15:20:42 -0600

> (e.g. if someone uses wildcards badly, which they do).

OK, I will add something to that effect in the next revisions.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Oct 2014 16:41:02 -0600

Stephen,

I'm working on updating these drafts and as I look again at the text that's
in §5. Interoperability Considerations and the requirement in §3 Assertion
Format and Processing Requirements to compare these values using the Simple
String Comparison (absent an application profile specifying otherwise) I'm
not sure what to say or where based on your suggestion below. Is there
something specific you can suggest (and where to put it)?

Thanks,
Brian

On Thu, Oct 16, 2014 at 3:20 PM, Brian Campbell <[email-masked]>
wrote:

>
> On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell <
> [email-masked]> wrote:
>
>>