…OIDC auth

For eherkenning authentication, this will contain the branch number
that the employee is authenticated/authorized for.

…OIDC auth

For eherkenning authentication, this will contain the branch number
that the employee is authenticated/authorized for.

…OIDC auth

For eherkenning authentication, this will contain the branch number
that the employee is authenticated/authorized for.

…OIDC auth

For eherkenning authentication, this will contain the branch number
that the employee is authenticated/authorized for.

This is really hard to test/try out because we don't have a real
eherkenning setup with a branch service restriction as far as I can
tell...

However, piecing together the documentation on:
https://afsprakenstelsel.etoegang.nl/Startpagina/v2/interface-specifications-dv-hm
(which describes the interface between service provider and makelaar),
we should get back the ServiceRestriction SAML attribute if information
is available in the MR (machtigingsregister). The examples show that
it would not be an encrypted attribute (it sits in the AttributeStatement
element):

    <saml:Attribute Name=urn:etoegang:1.9:ServiceRestriction:Vestigingsnr>
        <saml:AttributeValue xsi:type=xs:string>123456789012</saml:AttributeValue>
    </saml:Attribute>

The documentation says it would be one or more restriction, so we're
assuming that it returns a list of strings of values after processing,
similar to the urn:etoegang:core:ServiceID and urn:etoegang:core:ServiceUUID
attributes.

This is really hard to test/try out because we don't have a real
eherkenning setup with a branch service restriction as far as I can
tell...

However, piecing together the documentation on:
https://afsprakenstelsel.etoegang.nl/Startpagina/v2/interface-specifications-dv-hm
(which describes the interface between service provider and makelaar),
we should get back the ServiceRestriction SAML attribute if information
is available in the MR (machtigingsregister). The examples show that
it would not be an encrypted attribute (it sits in the AttributeStatement
element):

    <saml:Attribute Name=urn:etoegang:1.9:ServiceRestriction:Vestigingsnr>
        <saml:AttributeValue xsi:type=xs:string>123456789012</saml:AttributeValue>
    </saml:Attribute>

The documentation says it would be one or more restriction, so we're
assuming that it returns a list of strings of values after processing,
similar to the urn:etoegang:core:ServiceID and urn:etoegang:core:ServiceUUID
attributes.

I checked our code in django-digid-eherkenning, and we already by
default include the service restriction request in the catalogus
request, so no extra work should be needed there, see:
https://github.com/maykinmedia/django-digid-eherkenning/blob/0189aceea660d2f4774d238397365f17adeb354a/digid_eherkenning/models/eherkenning.py#L234