Exposing supported AuthnContextClasses in IdP Metadata

[Peter Schober]

Guillaume Rousse via users <users at shibboleth.net> [2026-09-18 16:16 CEST]:
> > 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 SFA/MFA specs only define these URIs as part of protocol messages
(authn requests, returned assertions/claims), *not* within SAML
metadata. I..e, use of these MFA/SFA URIs in the context of Entity
Attributes is fully undefined. I.e., you'd be making up your own
semantics using someone else's identifiers. Don't do that.

> 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.

While I sympathise, I also think it's wrong to look at this only from
the perspective of "reporting"/visibility/transparency: If the SFA/MFA
specs defined those URIs the way you desired (which they do not) it
would be in order to support reliable signalling of more secure
authentication requirements/results -- not to make your life (and
mine) easier as federation operators, by providing us (and our
respective constituencies) with public information to generate pie
charts from. (Hmm, pie...)

FWIW, the old eduGAIN Attribute Release Check
  https://release-check-old.edugain.org/ had permalinks to check
results I could search for and ingest.
While the new service
  https://release-check.edugain.org/
is much improved in every other aspect (e.g. it specifically supports
generating authn requests with REFEDS MFA authnContectClassRef or
without), it does not seem to archive those reports or make those
available with a publicly accessible link.
Maybe that's something we should ask for.

Best regards,
-peter