Shibboleth Developers

[Alistair Young <>]

I looked at eduPersonTargetedID but the spec states that it can't be 
shared across SP. i.e. you have to generate a unique one per SP. So it 
has to be an opaque handle. In effect, a user has a different ID for 
each SP - how to resolve those back to their real ID for assessment?
Perhaps I'm being a little vague (not surprising!)
The domain suffix is for IdP discovery without recourse to lists. It 
has no purpose other than that.
Once the IdP has been discovered and the user authenticated, it's then 
a question of identity. What to divulge and how.
SAML1 has a nameID but shibb defines it's own namespace for this which 
says it should be opaque and transient.
eduPersonPrincipalName looked promising but the spec says it may be 
deprecated in the next release
eduPersonTargetedID is not usable across multiple SP.
I haven't spotted this use case in SAML2 (maybe I'm missing something)
Alistair

On 1 Nov 2004, at 03:41, Scott Cantor wrote:

> > For static web pages, for example, Shibb/SAML is fine and the SP need 
> > not
> > know the identity of the user.
>
> Static vs. dynamic doesn't seem relevant, some applications need 
> identity
> and some don't.
>
> > It could track them using an anonymous ID that could be resolved by 
> > their
> > IdP to a real ID, or it could use their real ID from the start.
>
> Is that really true? Seems like most e-learning applications really 
> want
> identity, not just an opaque ID. I guess it depends on the 
> administrative
> model involved and what data changes hands...
>
> > For normal, static or non-assessed content, we don't see a need to 
> > use the
> > domain suffix. Rather, just use normal shibb/saml. It's just in the
> > context of eLearning that we need a way to allow tutors in the domain 
> > of
> > an IdP, to be able to gather assessment info on students at another 
> > domain
> > SP.
>
> I don't see what the domain suffix has to do with this. Needing a 
> persistent
> identifier is fine, but the suffix isn't unique to each user.
>
> > In a lot of cases, the user's ID is an impersonal, numeric 
> > identifier. I
> > could see privacy being catered for by having the IdP authenticate the
> > real ID but then issue an opaque, permanent, IdP resolvable ID to the 
> > SP,
> > which it can use to create a local user account in the VLE. The real 
> > ID
> > being discarded by the SP after authentication at the IdP.
>
> I would be looking at the eduPersonTargetedID attribute and more
> specifically the new SAMLv2 persistent identifier format that directly
> supports accounts linking via a federated identifier.
>
> In other words, the use case is already in the specs, there's nothing 
> you
> need invent here.
>
> -- Scott