Scenario: Consider a huge and diverse federation of Identity (IDPs) and Service (SPs) providers. Since trust level is generally low, Identity providers are reluctant to give out any kind of personal identifiable information (PII).

Now there are some services requiring PII, the respective SPs follow some higher standards that are certifiable by a known (to the IDPs in question) central instance.

Question: Is it possible that the central instance hands out some certificate (working like a server certificate with respect to signature and revocability) telling this is a specially trusted SP and the SP can present that certificate to the IDP who verifies it and than issues PII? Can it be implemented using SAML?

Note: Simple having some non-certified attribute on the SP is clearly a non-starter: Once that attribute becomes known to a potentially rogue SP, they can just steal (i.e., copy) it and use it themselves.

  • At first blush, this sounds like a problem made to order for Blockchain. Commented Apr 15, 2020 at 16:24

1 Answer 1


The SP sends a samlp:AuthnRequest when it wants a token. This request can be signed, and the IdP can decide whether the response should include whatever it wants. See section 3.4.1 "Element AuthnRequest".

However, which key is used to sign the request, who issues the certificate, and how the key ends up in the hands of the SP are out of scope of the protocol.

It also requires both parties support such a profile, as you can have IdP-Initiated and SP-Initiated requests.

Alternatively some services handle this problem by encrypting the attribute to a key only the SP knows and is built-in to the protocol. This too requires an out-of-band configuration, but can work with all profile types.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .