computedID in idpv3

[Tom Scavo]

On Sat, Feb 13, 2016 at 5:23 PM, Paul B. Henson <henson at cpp.edu> wrote:
> On Fri, Feb 12, 2016 at 09:51:30PM -0700, NATHAN KLINGENSTEIN wrote:
>
>> You may be in luck, because this is one of the degrees of freedom that
>> keeping these values in a database grants you.
>
> Well, yes, I'm familiar with the storedid option. But the reason I
> picked the computedid in the first place is that I want a highly
> available idp *without* the headache of trying to maintain a highly
> available database alongside of it 8-/. I've never really run into any
> of the "downsides" of the computedid, at least not to the point of
> making it worth adding an additional point of failure to my idp <sigh>.
>
> So if that's the long term plan, I guess I'll just wait for deprecated
> to turn into removed and worry about it then :).

I think two different "issues" are being slurred together:

1) computedid vs. storedid
2) eduPersonTargetedID vs. SAML2 Persistent NameID

Both you *and* Nate are right about the first issue. Bottom line: If
you're comfortable with the limitations of computedid, go for it.

The second issue is more interesting. Does your IdP support SAML2
only? If so, that's a no-brainer since you don't need ePTID. All your
needs are satisfied by SAML2 Persistent NameID.

However, if you still support SAML1, and you don't see that changing
in the near future, well, you might have to support both (ePTID and
SAML2 Persistent NameID) since I'm guessing the use of ePTID in SAML2
flows is on the way out.

Tom

PS. Time to put a stake in the ground wrt SAML1. At this point, any SP
that doesn't support SAML2 should be sent to their room without supper
;-)