Signature Services should use the Scoping element in AuthnRequests

[martin-lindstrom]

An Identity Provider serving an AuthnRequest sent from a signature service has no way of figuring out information about the actual service provider that invoked the signature service.

One organization may have several service providers, and they may all be using the same instance of signature service to provide signature services. The service providers may be differently configured. One may be intended for mobile devices (apps) and another one for an ordinary desktop. An IdP receiving requests from these service providers may then implement its services differently depending on what it knows about the service provider (it may even have configuration that is obtained by other means that reading SP metadata).

Now, the problem arises when one SP with a particular configuration at the IdP (and in SAML metadata) invokes a signature flow which eventually will lead to that the organization signature service generates an AuthnRequest and passes the user and request to the IdP. How will the IdP know which configuration to apply when the user should authenticate for signature? The organization signature service SP cannot be configured to suit all SP:s.

The suggestion is to recommend Signature Service SP:s to include the entityID of the SP that the user has authenticated at in the AuthnRequest (if available). An IdP may then, if needed, apply different behaviour for different calls from the same Signature Service SP by looking the the passed "orig SP entityID".

For this purpose the Signature Service SP should use the <saml2p:Scoping> element and in this element include a <saml2p:RequesterID> holding the entityID of the SP that initiated the call.

<saml2p:Scoping>
  <saml2p:RequesterID>http://www.origsp.com/sp</saml2:RequesterID>
</saml2p:Scoping>

Also see this thread in the discussion forum.

[Razumain]

As long as this information is optional, it will only provide opportunities and no burden. The issue is that certain IdP:s which to offer adapted behaviour for those SP that requires it. Unless this information is provided, the SP will get a default behaviour.

[martin-lindstrom]

Info: The test SP at https://eid.litsec.se/svelegtest-sp/sp has been updated so that a RequesterID may be included in AuthnRequest messages.