RFC 7773

Authentication Context Certificate Extension

📅 published March 2016, from ietf

Authentication Context Certificate Extension 🎀

Okay bestie, the title block is giving RFC 7773 ✨. It's a Standards Track doc from the IETF, written by S. Santesson at 3xA Security, dated March 2016, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here 🧚.

Abstract ✨

Okay so this doc defines an extension for X.509 certificates 📜. The extension holds data about how the certificate subject got authenticated by the Certification Authority (CA) that issued the certificate it lives in 🔥.

It also defines one data structure that goes inside this extension. That structure is built to hold info for when the subject gets authenticated with a Security Assertion Markup Language (SAML) assertion 💅.

Status of This Memo 💜

This one is an Internet Standards Track document 🌸.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚.

Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7773 🦋.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⭐.

Table of Contents 🍓

1. Introduction ....................................................2
   1.1. Terminology ................................................3
   2. Authentication Context Extension Syntax .........................4
   3. SAML Authentication Context Information .........................4
      3.1. contextInfo Data Structure .................................5
           3.1.1. AuthContextInfo Element .............................5
           3.1.2. IdAttributes Element ................................6
   4. Security Considerations .........................................8
   5. Normative References ............................................8
   Appendix A. ASN.1 Modules .........................................10
      A.1. ASN.1 1988 Syntax .........................................10
      A.2. ASN.1 2008 Syntax .........................................11
   Appendix B. SAML Authentication Context Info XML Schema ...........12
      B.1. XML Schema ................................................12
   Appendix C. SAML Authentication Context Info XML Examples .........14
      C.1. Complete Context Information and Mappings .................14
      C.2. Only Mapping Information without SAML Attribute Values ....15
      C.3. Authentication Context and serialNumber Mapping ...........16
   Author's Address ..................................................16

1. Introduction 🌸

The main goal here is to give an app a way to grab info that says who a subject is, based on an X.509 certificate, following [RFC5280] 🔍. That identity lives either in a subject field attribute, as a subject alternative name, or in a subject directory attribute.

Why this matters: an identity system and a certificate can use different attributes and data formats to describe the same entity, and we need to map between them 🔁. Usually the certificate subject already has an authenticated identity made of a set of attributes (aka claims). Those claims can be different from the attributes normally used for a certificate subject, and a specific certificate profile might limit that set 💅.

A super common setup is when user authentication and identity come from a SAML [SAML] federation attribute profile 🧠. In a SAML federation, the subject shows a SAML assertion and gets a certificate that can be tied back to info in that original assertion, like attributes and/or level of assurance indicators 🎀.

These certificates are sometimes issued so the user can make an electronic signature linking them to the SAML subject, its attributes, and its level of assurance indicators ✍️.

If a certificate has to follow a profile like [RFC3739] 📋, it might need a different set of attributes for the subject identity. It might also need attribute values in a different format from what the SAML assertion gives you 🙃.

This extension lets you represent info about the authentication context used when the subject was authenticated for certificate issuance 💖. That can include:

  • the Identity Provider that authenticated the subject
  • the level of assurance the subject was authenticated with
  • the trust framework where that level of assurance was defined
  • a unique reference to the authentication instant
  • a mapping between the subject attributes (from the SAML assertion used to authenticate the subject) and the subject identity info placed in the issued certificate

Here's a scenario where this is useful 👑: a user logs into a service with SAML credentials, and later that same user has to sign something. The service may need to check that the signature was made by the same user who logged in 🫶. Right now that only works with out-of-band knowledge about the Certification Authority (CA) that issued the certificate and its practices 😭. That approach doesn't scale to lots of service providers, identity providers, and CAs 💀.

The extension here scales way better, because only the service provider has to keep a list of trusted CAs ✨. All the other info about how the certificate subject relates to the SAML-authenticated subject lives right in the certificate 🦋.

1.1. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖.

2. Authentication Context Extension Syntax 🧚

The Authentication Context extension has this syntax 🎀:

AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF
                           AuthenticationContext

AuthenticationContext ::= SEQUENCE {
    contextType     UTF8String,
    contextInfo     UTF8String OPTIONAL
}

This extension holds a sequence of AuthenticationContext information. When it shows up, this extension MUST include at least one AuthenticationContext 🔥.

The type of authentication context defined in AuthenticationContext is identified by the contextType. The contextType MUST contain a URI that identifies the context type, plus the data format and encoding of the context info provided in contextInfo 💜.

This extension MAY be marked critical 🌈.

When an app finds an authentication context info type it doesn't understand, it MUST ignore it if the extension is non-critical, and it MUST reject the certificate if the extension is marked critical 🙈. If an app requires that an authentication context exists, and either the extension is missing or none of the provided authentication contexts can be used, the end-user certificate fails validation 💀.

This document defines one authentication context info type (Section 3) for giving info about SAML-based authentication of the subject, used in the certificate issuance process 🍓. Other documents can define other authentication context info types 🦋.

3. SAML Authentication Context Information 💖

The SAML Authentication context info gives you a contextType field that can carry info about SAML-based authentication of the certified subject, as used in the certificate issuance process 🌸.

The data in this authentication context info field is identified by the following XML schema ([Schema1] [Schema2]) name space:

http://id.elegnamnden.se/auth-cont/1.0/saci

When this URI is specified as contextType, the associated XML data in contextInfo MUST be provided as an XML document [XML], represented by a string of UTF-8-encoded characters 🎀.

The XML document SHOULD leave out any unnecessary line breaks and whitespace, like line indentation, so it's as small as possible 📦.

3.1. contextInfo Data Structure ✨

The data in contextInfo SHALL contain XML that is UTF-8 encoded, following the XML schema in Appendix B 🔥. The XML document string in contextInfo MUST NOT include an XML header. So the string only contains the root element <SAMLAuthContext> with its child elements <AuthContextInfo> and <IdAttributes> 💅.

The <AuthContextInfo> and <IdAttributes> elements are outlined in the subsections below 🧠.

3.1.1. AuthContextInfo Element 👑

The <AuthContextInfo> element MAY be present 🌈. This element has the following attributes 🫶:

  • IdentityProvider (required): The SAML EntityID of the Identity Provider that authenticated the subject.
  • AuthenticationInstant (required): The date and time when the subject was authenticated, expressed according to Appendix B.1 ⏰.
  • AuthnContextClassRef (required): A URI identifying the AuthnContextClassRef provided in the AuthnStatement of the Assertion that was used to authenticate the subject. This URI identifies the context and the level of assurance tied to this instance of authentication 🔐.
  • AssertionRef (optional): A unique reference to the SAML assertion 🦋.
  • ServiceID (optional): An identifier of the service that verified the SAML assertion 🧚.

The <AuthContextInfo> element may hold any number of child elements of type any (processContents="lax"), giving extra info according to local conventions 🍓. Any such elements SHOULD be ignored if they aren't understood 🙈.

3.1.2. IdAttributes Element 🎀

okay so the <IdAttributes> element is optional, bestie 💖 it MAY be present. It holds a sequence of one or more <AttributeMapping> elements, and each one contains mapping info about one certificate subject attribute or name form that's in the certificate ✨

Each <AttributeMapping> element MUST specify the following attributes:

  • Type: a string with one of the enumerated values "rdn", "san", or "sda" 💅 It says what kind of certificate attribute or name form the mapping is for:
    • "rdn": mapping info for an attribute in a Relative Distinguished Name that's in the subject field.
    • "san": mapping info for a name in the Subject Alternative Name extension of the certificate.
    • "sda": mapping info for an attribute in the Subject Directory Attributes extension.
  • Ref: a reference to the specific attribute or name field 🧚 What it holds depends on the Type:
    • "rdn": Ref holds a string representation of the object identifier (OID) of the relative distinguished name attribute.
    • "san": Ref holds a string representation of the explicit tag number of the Subject Alternative Name type (e.g., "1" = email address (rfc822Name) and "2" = dNSName). If the SubjectAlternative name is an otherName, then Ref holds a string representation of the OID defining the otherName form.
    • "sda": Ref holds a string representation of the OID of the subject directory attribute attribute.

String representations of OIDs in the Ref attribute MUST be a sequence of integers separated by a period, like "2.5.4.32" 🌸 The string can only contain numerals (ASCII 0x30 to 0x39) and periods (ASCII 0x2E), and it MUST NOT contain any other characters. No sneaky extras, periodt 🙈

Each <AttributeMapping> element MUST contain a <saml:Attribute> element as defined in [SAML]. That SAML attribute element MUST have a Name attribute (specifying its type), MAY have other attributes, and MAY have zero or more <saml:AttributeValue> child elements. A present SAML attribute with an absent attribute value limits the mapping to the type of SAML attribute that was used to get the value stored in the referenced certificate subject attribute or name form, without duplicating the actual attribute value. So it's giving "I know where this came from" without copy-pasting the value 🦋

If an attribute value is present in the SAML attribute, then the value stored in the certificate in the referenced attribute or name form MAY differ in format and encoding from the present SAML attribute value. For example, a SAML attribute value can specify a country as "Sweden", while that same country value is stored in the certificate in a countryName attribute using the two letter country code "SE". Same country, different outfit, ✨ iconic 👑

Several <AttributeMapping> elements MAY be present for the same certificate subject attribute or name form if the certificate has multiple instances of that attribute or name form and their values came from different SAML attributes. Here's the tea though: in that case, it's not defined which present subject attribute or name form maps to which SAML attribute 😭 A certificate-using application MAY try to figure this out by comparing attribute values stored in this extension with attribute or name values present in the certificate. This specification doesn't define any explicit matching rules that would guarantee an unambiguous result, so it's a little bit of a vibe check 💀

The <AttributeMapping> element may hold any number of child elements of type any (processContents="lax"), giving extra info according to local conventions. Any such elements MAY be ignored if they aren't understood. Totally chill, no drama 🫶

Note: The <AttributeMapping> element is designed to map between SAML attributes and certificate subject attributes and name forms where there's a distinct and clear relationship between the relevant SAML attributes and the corresponding certificate attributes and name forms. It does not cover every aspect of complex mapping situations. If more than one SAML attribute maps to the same certificate attribute, or if structured multivalued attributes are split across a range of other attributes and name forms, those situations are not covered.

Complex mapping situations like those MAY be covered by extending this XML schema or by defining a more versatile context information schema 🌈 Future us can handle it, bestie.

4. Security Considerations 🔥

Okay, serious moment, I need you to lock in 🔒 This extension lets a CA outsource the process it uses to identify and authenticate a subject to another trust infrastructure. It can do that dynamically, and the process can be different from certificate to certificate. Since the authentication context is explicitly declared in the certificate, one certificate may be issued with a lower level of assurance than another, even though both have the same Issuer. Not the same vibes at all 😳

That means a relying party needs to know the certificate policy that this CA operates under, so it can tell when a certificate gives a level of assurance for subject authentication that's higher than the lowest provided level. This is the main event, so read it twice:

A relying party that is not capable of understanding the information in the authentication context extension MUST assume that the certificate is issued using the lowest allowed level of assurance declared by the policy. ⚠️ No guessing, no benefit of the doubt, just assume the lowest 💀

5. Normative References 📚

Appendix A. ASN.1 Modules 🧚

This appendix has the ASN.1 modules for the authentication context extension. Appendix B.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1. Appendix B.2 includes an ASN.1 module, corresponding to the module in Appendix B.1, that conforms to the 2008 version of ASN.1. Even though a 2008 ASN.1 module is provided, the module in Appendix B.1 remains the normative module, per the policy the PKIX working group adopted for certificate-related specifications 📜 Main character rule: B.1 is the one that counts 👑

A.1. ASN.1 1988 Syntax

 ACE-88
       {iso(1) member-body(2) se(752) e-legnamnden(201)
        id-mod(0) id-mod-auth-context-88(1)}

 DEFINITIONS EXPLICIT TAGS ::=

 BEGIN

 -- EXPORTS ALL --

 -- Authentication Context Extension

 AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF
                            AuthenticationContext

 AuthenticationContext ::= SEQUENCE {
     contextType     UTF8String,
     contextInfo     UTF8String OPTIONAL
 }

 e-legnamnden      OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                                           se(752) 201 }
 id-eleg-ce        OBJECT IDENTIFIER ::= { e-legnamnden 5 }
 id-ce-authContext OBJECT IDENTIFIER ::= { id-eleg-ce 1 }

 END

A.2. ASN.1 2008 Syntax

 ACE-08
       {iso(1) member-body(2) se(752) e-legnamnden(201)
        id-mod(0) id-mod-auth-context-08(2)}

 DEFINITIONS EXPLICIT TAGS ::=
 BEGIN
 EXPORTS ALL;
 IMPORTS

 Extensions{}, EXTENSION
 FROM PKIX-CommonTypes-2009 -- From [RFC5912]
     {iso(1) identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)};

 -- Authentication Context Extension

 ext-AuthenticationContext EXTENSION ::= { SYNTAX
        AuthenticationContexts IDENTIFIED BY
        id-ce-authContext }

 AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF
                            AuthenticationContext

 AuthenticationContext ::= SEQUENCE {
     contextType     UTF8String,
     contextInfo     UTF8String OPTIONAL
 }

 ElegnamndenCertExtensions EXTENSION ::= {
     ext-AuthenticationContext, ... }



 e-legnamnden      OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                                           se(752) 201 }
 id-eleg-ce        OBJECT IDENTIFIER ::= { e-legnamnden 5 }
 id-ce-authContext OBJECT IDENTIFIER ::= { id-eleg-ce 1 }

 END

Appendix B. SAML Authentication Context Info XML Schema 🌸

This appendix has an XML schema ([Schema1] [Schema2]) for the SAML Authentication context information defined in Section 3 ✨

IMPORTANT NOTE: The XML Schema in Appendix B.1 specifies a URL on rows 9 and 10 to the SAML schemaLocation (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd), which is too long to fit into one row and therefore contains a line break. This line break has to be removed before this schema can be successfully compiled. 🙏 Don't skip this one, bestie, it'll break your whole day 💀

B.1. XML Schema 🎀

Okay bestie, this is the actual XML Schema for everything we've been talking about, so it's basically the rulebook in code form ✨ It's the file that tells a parser what a valid SAMLAuthContext looks like, and it's very picky about it 💅

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified"
    targetNamespace="http://id.elegnamnden.se/auth-cont/1.0/saci"
    xmlns:saci="http://id.elegnamnden.se/auth-cont/1.0/saci"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

    <xs:import namespace="urn:oasis:names:tc:SAML:2.0:assertion"
        schemaLocation="http://docs.oasis-open.org/security/saml/v2.0/
saml-schema-assertion-2.0.xsd"/>

    <xs:element name="SAMLAuthContext"
                type="saci:SAMLAuthContextType"/>
    <xs:complexType name="SAMLAuthContextType">
        <xs:sequence>
            <xs:element ref="saci:AuthContextInfo" minOccurs="0"/>
            <xs:element ref="saci:IdAttributes" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>
    <xs:element name="AuthContextInfo"
                type="saci:AuthContextInfoType"/>
    <xs:complexType name="AuthContextInfoType">
        <xs:sequence>
            <xs:any processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="IdentityProvider"
                      type="xs:string" use="required"/>
        <xs:attribute name="AuthenticationInstant"
                      type="xs:dateTime" use="required"/>
        <xs:attribute name="AuthnContextClassRef"
                      type="xs:anyURI" use="required"/>
        <xs:attribute name="AssertionRef" type="xs:string"/>
        <xs:attribute name="ServiceID" type="xs:string"/>
    </xs:complexType>

    <xs:element name="IdAttributes" type="saci:IdAttributesType"/>
    <xs:complexType name="IdAttributesType">
        <xs:sequence>
            <xs:element maxOccurs="unbounded" minOccurs="1"
                        ref="saci:AttributeMapping"/>
        </xs:sequence>
    </xs:complexType>
    <xs:element name="AttributeMapping"
                type="saci:AttributeMappingType"/>
    <xs:complexType name="AttributeMappingType">
        <xs:sequence>
            <xs:element ref="saml:Attribute"/>
            <xs:any processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="Type" use="required">
            <xs:simpleType>
                <xs:restriction base="xs:string">
                    <xs:enumeration value="rdn"/>
                    <xs:enumeration value="san"/>
                    <xs:enumeration value="sda"/>
                </xs:restriction>
            </xs:simpleType>
        </xs:attribute>
        <xs:attribute name="Ref" type="xs:string" use="required"/>
    </xs:complexType>
</xs:schema>

Appendix C. SAML Authentication Context Info XML Examples 🧚

Time for the fun part!! 🫶 This appendix is full of examples of SAML Authentication Context information that follow the schema in Appendix B. Think of them as the outfit ideas that show you exactly how the schema looks when it's worn 👗💖

C.1. Complete Context Information and Mappings 🌸

Here's a full example with authentication context info AND mapping info for several subject field attributes plus a subject alt name. It's giving everything 😭✨

<saci:SAMLAuthContext
    xmlns:saci="http://id.elegnamnden.se/auth-cont/1.0/saci"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <saci:AuthContextInfo
        ServiceID="eid2csig"
        AssertionRef="_71b981ab017eb42869ae4b62b2a63add"
        IdentityProvider="https://idp-test.nordu.net/idp/shibboleth"
        AuthenticationInstant="2013-03-05T22:59:57.000+01:00"
        AuthnContextClassRef="http://id.elegnamnden.se/loa/1.0/loa3"/>
    <saci:IdAttributes>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.6">
            <saml:Attribute
                FriendlyName="Country"
                Name="urn:oid:2.5.4.6">
                <saml:AttributeValue xsi:type="xs:string"
                    >SE</saml:AttributeValue>
            </saml:Attribute>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.5">
            <saml:Attribute
                FriendlyName="Personal ID Number"
                Name="urn:oid:1.2.752.29.4.13">
                <saml:AttributeValue xsi:type="xs:string"
                    >200007292386</saml:AttributeValue>
            </saml:Attribute>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.42">
            <saml:Attribute
                FriendlyName="Given Name"
                Name="urn:oid:2.5.4.42">
                <saml:AttributeValue xsi:type="xs:string"
                    >John</saml:AttributeValue>
            </saml:Attribute>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.4">
            <saml:Attribute

                FriendlyName="Surname"
                Name="urn:oid:2.5.4.4">
                <saml:AttributeValue xsi:type="xs:string"
                    >Doe</saml:AttributeValue>
            </saml:Attribute>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.3">
            <saml:Attribute
                FriendlyName="Display Name"
                Name="urn:oid:2.16.840.1.113730.3.1.241">
                <saml:AttributeValue xsi:type="xs:string"
                    >John Doe</saml:AttributeValue>
            </saml:Attribute>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="san" Ref="1">
            <saml:Attribute
                FriendlyName="E-mail"
                Name="urn:oid:0.9.2342.19200300.100.1.3">
                <saml:AttributeValue xsi:type="xs:string"
                    >john.doe@example.com</saml:AttributeValue>
            </saml:Attribute>
        </saci:AttributeMapping>
    </saci:IdAttributes>
</saci:SAMLAuthContext>

C.2. Only Mapping Information without SAML Attribute Values 🦋

This one is the minimalist look 🤍 It's just a mapping table, with no authentication context info and no SAML attribute values. Iconic restraint, honestly 💅

<saci:SAMLAuthContext
    xmlns:saci="http://id.elegnamnden.se/auth-cont/1.0/saci"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saci:IdAttributes>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.6">
            <saml:Attribute Name="urn:oid:2.5.4.6"/>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.5">
            <saml:Attribute Name="urn:oid:1.2.752.29.4.13"/>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.42">
            <saml:Attribute Name="urn:oid:2.5.4.42"/>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.4">
            <saml:Attribute Name="urn:oid:2.5.4.4"/>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.3">

            <saml:Attribute Name="urn:oid:2.16.840.1.113730.3.1.241"/>
        </saci:AttributeMapping>
        <saci:AttributeMapping Type="san" Ref="1">
            <saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.3"/>
        </saci:AttributeMapping>
    </saci:IdAttributes>
</saci:SAMLAuthContext>

C.3. Authentication Context and serialNumber Mapping 🌈

This example has both the authentication context info and a mapping that says where the data in the serialNumber attribute of the subject field comes from. It's the two-piece set, and it's so cute 🥹🎀

<saci:SAMLAuthContext
    xmlns:saci="http://id.elegnamnden.se/auth-cont/1.0/saci"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <saci:AuthContextInfo
        ServiceID="eid2csig"
        AssertionRef="_71b981ab017eb42869ae4b62b2a63add"
        IdentityProvider="https://idp-test.nordu.net/idp/shibboleth"
        AuthenticationInstant="2013-03-05T22:59:57.000+01:00"
        AuthnContextClassRef="http://id.elegnamnden.se/loa/1.0/loa3"/>
    <saci:IdAttributes>
        <saci:AttributeMapping Type="rdn" Ref="2.5.4.5">
            <saml:Attribute
                FriendlyName="Personal ID Number"
                Name="urn:oid:1.2.752.29.4.13">
                <saml:AttributeValue xsi:type="xs:string"
                    >200007292386</saml:AttributeValue>
            </saml:Attribute>
        </saci:AttributeMapping>
    </saci:IdAttributes>
</saci:SAMLAuthContext>

Author's Address 💌

Stefan Santesson
3xA Security AB
Scheelev. 17
223 70 Lund
Sweden
Email: sts@aaa-sec.com
📦 where this page comes from