Andy Swiffin wrote:

> Would it be possible to split the requirement rather than lumping
> PrincipleName and targetedID together?

The short answer is no, the Rules of Membership deliberately bundle
various behavioural rules together so that service providers only really
have two classes of IdP to deal with (section 6 compliant and "everyone
else"). Your saying "yes, we do everything in section 6" is just a
simple way for you to convey that bundle of guarantees via the
federation rather than having to negotiate with each SP independently.

If the bundle isn't appropriate, of course, there is nothing stopping
you having a more detailed discussion with each SP you want to deal
with. As (we hope) very few of them will need ePPN, that might be
viable in some cases. Life is likely to be easier if you can sign up to
section 6, though.

[lots of good analysis snipped]

> Of course this all assumes that PrincipalName is the users actual login
> ID - does it have to be? Could it be like the targettedID, some
> obfuscated version of the matric/staff code?

I think my first observation would be that I'm surprised that frequent
reuse of login IDs isn't causing you headaches elsewhere already. But
your question here is the critical one, I think.

The Technical Recommendations for Participants cover this (in 7.1.4).
We are less absolute than eduPerson with regards to ePPN, because we
realise there may be issues with reassignment of login names in some
institutions .

The eduPerson specification is clear that the expectation is that the
eduPersonPrincipalName is the identifier used to authenticate the user.
 The main reason I can see for wanting this to be the case are to do
with the user therefore being aware of the value, so that it can be used
in out-of-band communications. For example, my ePPN is [log in to unmask]
(same as my e-mail address) and I can phone someone up and say "my ePPN
is [log in to unmask], please add me to that access control list".

In practice, if you reassign login IDs and you wanted to sign up to
having stable ePPN values, using some value other than the login ID
would work just fine. You probably would want to think about how far
you wanted to obfuscate it; if one of your students asks you what their
ePPN is for reading over the phone to someone to put into an ACL, you
don't want to have to deal with something like this:

[log in to unmask]

On the other hand, this might be acceptable:

[log in to unmask]

> Well, yes, but, as Jon pointed out earlier:
>
> "The Internet2 software only supports hashing on the fly. You can
> presumably
> extend it, given sufficient Java skill, to support only computing the
> value once."
>
> I'm not sure I feel brave enough to start hacking round with the code
> right at the outset....

The good news is that there are various people out there who have
already put together systems that work with an external database in the
way described. If one of them is listening, pitch in here please!

The only reason such a facility hasn't been bundled into the standard
IdP is that making it work "out of the box" would require the bundling
of an SQL database with the IdP distribution...

It does, however, seem like we should be pointing people at one or more
standard database-backed implementations of ePTI if we can find some
that are well enough documented.

Oh, and as a by-the-way, I'd note that some more good news is that as of
IdP 1.3.2, the IdP has apparently acquired a nice ability to do random
attribute computation in "scriptlets". This might make it easier to put
this kind of extension together in future. Documentation here:

https://spaces.internet2.edu/display/SHIB/ScriptletAttributeDefinition

-- Ian