RE: [imi] SAML 2 profile questions

["Scott Cantor" <cantor.2@osu.edu>]

> If you are using bearer assertions, then the presence of the authn token
> only provides extra granularity for access control if it contains
> a) the LOA value and/or
> b) a permanent ID of the user that is known to the SP.

We're talking about the statements in the "token". AuthnStatements do not
contain information about the user, but about the act of authentication that
led to the issuance of the assertion.

> My preferred model is that the attribute statement is mandatory and the
> authn statement is optional and is only present if it provides some
> valid purpose, such as a permanent ID, LOA or proof of possession token.

It includes a number of useful bits, including communicating the time of
authentication, authentication context (which is often profiled into LOA),
details about the client, and a hint about session length. It has nothing to
do with permanent IDs or proof of possession.

It's not directly possible to require an attribute statement because there's
nothing mandatory to put there. This is not the case with an authn
statement.

> > In 2.3.3, the draft states that "the assertion MUST be signed".  I
> > understand the value of this, but I'd like us to at least discuss this
> > before assuming that this should be a MUST.  For instance, is this a
> > MUST when the token is used with the SAML 2.0 protocol?
> 
> In many cases TLS is sufficient, so I see no need to make this mandatory.

The signature is for integrity of the assertion from the IdP. There is no
TLS connection between the IdP and the RP. Not signing the token means a
client is free to manipulate it at will.
 
> This is clearly more dangerous than a bearer credential with an audience
> restriction. But on a scale of 1 to 100, where would you place both
> types of bearer credentials as opposed to pop credentials which are
> placed at one end of the scale. I dont think they are orders of
> magnitude appart, and would be relatively close together on this scale.

I mostly agree, but I don't believe most of the people out there understand
the issue, and people only pay attention to strong wording.

> If you want privacy protection then you can always use a freshly minted
> randomly generated identifier to identify the user in each new assertion

That doesn't address the privacy use case that non-audited cards are
intended to address, which is about privacy *from* the IdP regarding what
RPs you visit.

My complaint is not with non-auditing mode, it's with the lack of support
for holder of key when using it.

-- Scott