RE: [saml-dev] "previously established an identifier usable by the requester"?

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

> Ironically, Scott, it was something you said a while back that led me to
> a more strict reading.

Oops. I probably said that I didn't think persistent was all that special a
case. And I don't. That doesn't mean it doesn't have differences in typical
(I say typical, not universal) use.

> But I digress - it's certainly not my place to
> tell the spec authors what their intent was :)

I try not to argue from authority (even my own). And I don't especially like
or understand the full intent of AllowCreate, so this isn't a place where
I'd be comfortable speaking definitively.

> Again, who am I to disagree with the spec authors?  But my reading led
> me to a different interpretation.  Perhaps it's the wrong interpretation
> (wouldn't be the first time) but I would argue that there is sufficient
> confusion around the issue that perhaps the whole subject deserves
> treatment in errata.  

With respect to the X.500 question and how AllowCreate would or wouldn't
preclude universal pre-assignment, I do slightly beg to differ that most
people have had a major problem seeing that as explicitly allowed. The
interop scenario alone suggests that much. But I think we're happy to
address that in an eventual impl guidelines doc (or an erratum if there's an
obvious wording change).

The rest of the confusion is real, I don't argue that point. And I do agree
that once you allow that qualifier, it's not clear what AllowCreate really
buys you. As a further example, consider attributes. If I set AllowCreate
false, nothing prevents the IdP from creating and sending a SAML attribute
containing a persistent value. AllowCreate only addresses NameID. That
probably makes this look even worse. ;-)

> I'm not aware of anywhere in the spec that treats AllowCreate as a
> consent issue - I would have thought that consent was wholly dealt with
> via the Consent attribute on requests and responses.

The underlying reasoning behind AllowCreate as I understand it is consent.
It's about the SP indicating whether it's ok with the "implications" of the
IdP creating a NameID, if it has to. Because in some use cases, that action
is interpreted as significant and worthy of explicit user consent.

Personally I think it's the *release* of that identifier (whenever it is
created and however it might be passed) that needs consent. Creation seems
irrelevant to me, since if I don't release it, it doesn't matter whether it
exists or not. Architecturally, the user always has that potential in an IdP
implementation to block it.

> Point taken.  But let me play the devil's advocate for a second:
> wouldn't it be possible to link in that situation by having the SP
> authenticate the user and then use NIM to register a SPProvidedID?

No, not practically speaking.

> Granted it's a funky usage but I don't recall anything in the 
> spec that precludes it. 

Transient is generally N/A for NIM. The spec says this, but I think in
retrospect I should have made that sentence stronger. In general, it's
simply NOT expected to be used with it.

Remember, the alias is attached as part of the NameID. It doesn't have a
definition in SAML independently of it. For example, if you register an SP
alias against a persistent NameID, if that IdP sends you an X.500 name at
some point, it will NOT necessarily have your alias attached unless you also
register the alias against that NameID.

If that's not clear, we need to add this. The NameID XML is an atomic unit
and the NIM protocols are manipulating them as atoms. It's an implementation
choice, I suppose, to relate NameIDs like that, but the spec certainly
doesn't require it. But I think the text is a little vague there, you're
right. It talks about "this principal" when it really means "this NameID".

I'm not sure there's a ton of expected uses cases for an IdP using all kinds
of different formats for a given principal with a given SP, and I think
that's probably why these cases aren't as clearly addressed as they might be
<defense level="weak"/>.

> I guess it's not so obvious to me and I was trying to interpret the spec
> in a way that would mitigate such non-interoperable deployment modes.
> Maybe that's too far fetched.  

If I'm using RSA and you're using DSA...it's hardly confined to the high
level stuff. Just perhaps easier for us geeks to understand.

> If there are such mutually exclusive deployment modes, it's not obvious
> to me what they are.  What's the differentiating factor?  Name id format
> support?  Operational modes as defined in the conformance spec?  Or
> something else?

The business meaning you attach to the information you're exchanging, for
one thing. What the application expects to do with it. This applies to
anything. SAML can't standardize the meaning of most of the information it
exchanges. There are a few exceptions, but not many.

But any place there's optionality, you can end up mutexing yourself out of
operation. I might configure my IdP for X.500 and you expect persistent. Or
I only do transient. Or I expect Authn Context and you deploy without it. Or
my application needs attributes and you don't supply them.

The conformance spec is pretty heavy, because we wanted as many options to
be MTI as possible, but that makes things bigger and harder, of course.

> I don't follow this - what do you mean by provisioning?  Provisioning a
> new account?  Provisioning the identifier (pair wise or otherwise)?
> Something else?

Provisioning an identifier, to the extent that you can define that. The spec
doesn't, it only alludes to it as the act of "creating an identifier for an
SP".

> I see what you are saying but it seems odd to me to have messages that
> are really only informational that the other party can act on, or not.

I don't see anything at all unusual about that. We can't mandate the context
in which the message's meaning is going to be interpreted. I would expect
most implementations to pass the notification to an event sink, as well as,
or even in place of, acting on it.

> And actually my question was more about the SP using NIM to register a
> SPProvidedID.  

See above, but I think I see where the confusion is now, perhaps...

> And, as a product developer, that's what I have a hard time with.

I'll push back slightly and note that, personally, I find the lack of
standardization of trust to be a much bigger and harder problem. And the one
that causes more customer problems. I don't think there's anything we can do
about it, but my point is this stuff is hard, and it gets hard as you go
both above and below the SAML layer and try and accommodate everything you
might hit there.

-- Scott