Exposing supported AuthnContextClasses in IdP Metadata

Guillaume Rousse guillaume.rousse at renater.fr
Fri Sep 18 14:16:07 UTC 2026


I'm sorry for the long delay before being able to continue the discussion.

----- Mail original -----
 > De: "Peter Schober via users" <users at shibboleth.net>
 > À: users at shibboleth.net
 > Cc: "Peter Schober" <peter.schober at univie.ac.at>
 > Envoyé: Vendredi 26 Juin 2026 14:52:24
 > Objet: Re: Exposing supported AuthnContextClasses in IdP Metadata

 > Guillaume Rousse via users <users at shibboleth.net> [2026-06-26 14:04 
CEST]:
 >> I'm currently hesitating between two options:
 >> - a multivalued entity attribute
 >> - a dedicated metadata extension
 >
 > You may be missing a third one:
 > 
https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html

Unless I'm wrong, this correspond to the first option, ie using an 
entity attribute. That would be an already-existing attribute, tough, 
and not a brand new one. It would results in the following fragment, for 
a SIRTFI-compliant IdP supporting both SFA and MFA refeds profiles:

|<mdattr:EntityAttributes> <saml:Attribute 
Name="urn:oasis:names:tc:SAML:attribute:assurance-certification" 
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> 
<saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue> 
<saml:AttributeValue>https://refeds.org/profile/sfa</saml:AttributeValue> 
<saml:AttributeValue>https://refeds.org/profile/mfa</saml:AttributeValue> 
</saml:Attribute> </mdattr:EntityAttributes>|

 >> The first one seems the easiest to achieve (no additional schema 
needed) A
 >> dedicated metadata extension would however provide a better 
visibility, but
 >> may have unwanted impact on other SAML implementation.
 >
 > "Better visibility" in what way, exactly -- are you assuming people
 > are eyeballing your XML? Or in the sense of the latter argument, that
 > (potential) breakage would provide additional exposure? ;)

As federation operators, we are trying to provide visibility in our 
community, so as to reduce the chicken-and-egg issue: in order to 
convince SP admins they can begin using explicit AuthnContext 
requirements in their SAML requests, we have to convince them a 
reasonable part of our community will be able to answer those requests. 
Exposing this information may be human-targeted, though pretty diagrams, 
as we already do with other kind of compliance 
(https://registry.federation.renater.fr/federations/view/4), but may as 
well be machine-targeted, through metadata, as a small bonus. Even if 
there is no evidence of direct usage, indeed.

Regards.

-- 
Guillaume Rousse
Direction des Services Applicatifs
RENATER - Paris


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4330 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20260918/87f02645/attachment.p7s>


More information about the users mailing list