Shibboleth Developers

["Scott Cantor" <>]

> 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