RE: [security-services] ECP and Saml 2.0 persistent identifiers

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

> Does anyone know (perhaps I missed it in the Saml 2 specs), 
> do persistent ids just NOT apply to ECP clients/proxies?

Certainly they do, they both came from ID-FF...

> Two things I saw that imply this:
>  
> 1. At the SP, the initial response when requesting a resource 
> is that is has to send an AuthnRequest message that is meant 
> for an IDP. Why isn't the SP allowed to ask the ECP for a 
> local login first (if that's possible). 

I don't follow, what does this have to do with persistent IDs or ECP? If the
SP doesn't want to send a request, it doesn't have to...

> Consider the case where the user is federating for the first 
> time, the ECP needs to do a local login as well after the 
> AuthnRequeest/Reponse happens.

Local login is out of scope of SAML, nor is it required for persistent IDs.

> 2. There is no PAOS type of processing for MNI requests (but 
> neither is there SLO requests). Perhaps in this case 
> HTTP-Redirects work as usual (but it begs the question why 
> HTTP Red AutnRequests and HTTP Artifact couldn't be used with ECP).

The reason is that ECP only exists because the EC knows where the IdP is.
That's the advantage. MNI and related activities are not sent into the ether
for dispatch by the client. The SP knows exactly where to send the message
(via the client or directly).

The PAOS processing is because the EC is an active intermediary. There's no
need for one in the other protocols.

-- Scott