~Re: Storing persistentId using an HTTP DataConnector

[Peter Schober]

* spf via users <users at shibboleth.net> [2022-11-04 14:37]:
> Is it also possible to generate "eduPersonTargetedID" the same way
> (reusing the computed id) but with the same format as before, as a
> "EntityID!hPeerID!PersistentID" string ?
> I think this is what you call putting a NameID in an AttributeValue.

I forgot to mention that the specific format you show above is NOT was
is put into the SAML Assertion and/or sent on the wire: That's merely
the canonical (and somewhat arbitrary) serialisation into string form
that the Shibbolth SP uses/popularised. Which does not need to concern
us as IDP deployers (i.e., this is purely local to the SP and the
resources it protects).

On the wire the attribute value literally is a SAML persistent NameID
XML element, *not* a serialised string representation of that same
3-tuple, e.g.:

  <saml2:Attribute FriendlyName="eduPersonTargetedID" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>
      <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://example.org/idp" SPNameQualifier="https://sp.example/saml">ZXhhbXBsZQ==</saml2:NameID>
    </saml2:AttributeValue>
  </saml2:Attribute>

> Maybe it will not be useful in the future, but as some SPs I have
> seen in the federation require it, better provide it.

As I said before, if you configure your IDP to produce the above it
will already inform you that this specific construct has no future.

I agree that there are still SPs around that may not work without
eduPersonTargetedID, even with a proper NameID (in the Assertion's
Subject element) was present.
For a while I sent error reports to some (where I leared of this) but
with saml2int v2.0[1] and SubjectID/PairwiseID the replacement for
eduPersonTargetedID is no longer "proper" NameIDs but PairwiseID.

Best,
-peter

[1] https://kantarainitiative.github.io/SAMLprofiles/saml2int.html