Peter Schober peter.schober at
Fri Feb 23 10:51:10 EST 2018

* Cantor, Scott <cantor.2 at> [2018-02-23 15:41]:
> > Ignore the filter for persistent NameIDs when configured as above.
> > The above is all you need /if/ you wanted to use persistent NameIDs.
> > Scott will say you shouldn't. ;)
> Scott will mostly just ask what he could possibly write that would
> have answered all these questions, because I don't know what else to
> do. The wiki page is as specific about the settings as I can make
> it.

Indeed. Wrt generation strategies (and capturing this thread a bit):
Is there a way to generate valid pairwiseIDs (per the new OASIS
Attribute Profile) using the Computed strategy, while at the same time
keeping support for existing "computed" persistent NameIDs?

I can't change the encoding in to BASE32
without killing all computed persistent NameIDs released to SPs.
I'm not keen on setting idp.persistentId.computed to an empty value as
I'd then had to persist values for real.
I can't add a definition for pairwise to the attribute resolver (using
the ComputedId type DataConnector, v2-style, and a Scoped attribute
definition) as the old strategy doesn't satisfy the syntactic
requirements of the new attribute.

For (omni-directional) subjectID itself I'm currently creating salted
sha256 hashes in a ScriptedAttribute attribute definition. I guess I
could do the same for pairwise but would have to dig deeper to also
get the SP's entityID from the context tree to put into the hash.


More information about the users mailing list