RFC 6711

An IANA Registry for Level of Assurance (LoA) Profiles

📅 published August 2012, from ietf

An IANA Registry for Level of Assurance (LoA) Profiles 🎀

(Part 1 of 2)

RFC 6711 💖 is from the Internet Engineering Task Force (IETF). Its author is L. Johansson of NORDUNet. It's Informational (published for information, not a standard), dated August 2012, with ISSN 2070-1721. It doesn't obsolete or update any other RFCs. ✨

Abstract 🌸

okay so this doc sets up an IANA registry for Level of Assurance (LoA) Profiles 📋. The idea is that it's a place to find LoA definitions, so protocols that use the LoA concept can look them up. The main ones are Security Assertion Markup Language (SAML) 2.0 and OpenID Connect 🦋.

Status of This Memo 📝

This doc is not an Internet Standards Track spec. It's published just for info 💅.

It's a product of the IETF, so it reflects what the IETF community agreed on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 👀.

For the current status, any errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc6711 🔗.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Please read them carefully, because they spell out your rights and restrictions. Code Components pulled from this doc 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
2. Name of Registry ................................................3
3. Registration Template ...........................................3
   3.1. Example Registration .......................................4
   3.2. Note on the Example ........................................5
4. Registration Policy .............................................5
   4.1. Reviewer Expectations ......................................5
5. Registry Semantics ..............................................6
6. IANA Considerations .............................................6
7. Security Considerations .........................................7
8. Acknowledgements ................................................7
9. References ......................................................7
   9.1. Normative References .......................................7
   9.2. Informative References .....................................7

1. Introduction 🧚

So this doc creates an IANA registry for LoA Profiles, full stop 🎯.

[SAML] has this definition of "level of assurance" that's honestly so good:

Many existing (and potential) SAML federation deployments have adopted a "levels of assurance" (or LOA) model for categorizing the wide variety of authentication methods into a small number of levels, typically based on some notion of the strength of the authentication. Federation members (service providers or "relying parties") then decide which level of assurance is required to access specific protected resources, based on some assessment of "value" or "risk".

RFC 4949 [RFC4949] defines "assurance level" too, and it traces these profiles back to the NIST special publication series, especially SP 800-63 [SP63] 📚. LoA Profiles show up in lots of protocols, including SAML version 2.0 and OpenID Connect 🌈.

There are a bunch of so-called trust frameworks and identity federations now, and some of them define one or more LoAs. This spec exists so those LoA definitions can be discovered in one spot 🔍. Even though the quote mentions SAML, the LoA idea has become super mainstream and should be treated as protocol-independent ✨. The new registry tries to show that.

The registry will hold URIs that point at SAML Authentication Context Profiles. But other protocols can use those URIs to identify LoA definitions too, without depending on or sending the SAML XML definitions 🫶. Using the registry from protocols other than SAML is encouraged 💅.

For example, OpenID Connect defines the standard claim 'acr' as an identifier that can reference a SAML Authentication Context Class, even though OpenID Connect isn't based on XML or SAML at all 🤯.

If you're a protocol designer who wants to reference the registry, heads up: registered LoAs might rely on assumptions that don't carry over to every protocol, and those assumptions can differ between the protocols the LoAs were originally registered for ⚠️.

2. Name of Registry 📛

The registry's name shall be "Level of Assurance (LoA) Profile", and the plural is "Level of Assurance (LoA) Profiles" 💖.

3. Registration Template 📄

Each registration must include the following info:

  • URI: A URI referencing a Level of Assurance Profile. This is the registry key 🔑.
  • Context Class: A valid XML schema definition for the SAML 2.0 LoA Context Class that fulfills the requirements of [SAML]. The registry key (the URI) is the unique identifier for the Context Class 🆔.
  • Name: A string that uniquely and unambiguously identifies the LoA, for use in protocols where URIs aren't appropriate 🏷️.
  • Informational URL: A URL with auxiliary info. This URL must at minimum reference contact information for the administrative authority of the LoA definition, and it must use either the http or https scheme 📞.

Quick note: one SAML Authentication Context Class can define multiple URIs. In that case, use a separate registration for each URI 🍓. Both the name and the URI have to uniquely and unambiguously identify the LoA. The name exists for protocols where URIs aren't appropriate. The requester is also expected to give basic contact info and the name of the organization the LoA definition is registered on behalf of 🧾.

The name is defined by this ABNF (from RFC 5234 [RFC5234]) 🧩:

label = ( ALPHA / DIGIT )
name = label 1*( label / "-" / "." / "_" )

The ABNF productions below represent reserved values for the name element. They are not to be registered 🚫:

reserved = loa / al / num
loa = ( "l" / "L" ) ( "o" / "O" ) ( "a" / "A") *DIGIT
al = ( "a" / "A") ( "l" / "L") *DIGIT
num = *DIGIT

The reason for excluding these is to avoid a race to register overly generic LoA Profiles with names like "AL1" or "LOA2" 🏁.

3.1. Example Registration 🎀

  1. Name of requester: J. Random User
  2. Email address of requester: jrandom@example.com
  3. Organization of requester: Example Trust Frameworks LLP
  4. Requested registration:
URI  http://foo.example.com/assurance/loa-1
Name  foo-loa-1
Informational URL  https://foo.example.com/assurance/

SAML 2.0 Authentication Context Class Definition 🌷

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    targetNamespace="http://foo.example.com/assurance/loa-1"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="http://foo.example.com/assurance/loa-1"
    finalDefault="extension"
    blockDefault="substitution"
    version="2.0">
  <xs:redefine
     schemaLocation="saml-schema-authn-context-loa-profile.xsd">
      <xs:annotation>

          <xs:documentation>
              Class identifier:
                  http://foo.example.com/assurance/loa-1
                  Defines Level 1 of the Foo Assurance Framework
          </xs:documentation>
      </xs:annotation>
      <xs:complexType name="GoverningAgreementRefType">
        <xs:complexContent>
          <xs:restriction base="GoverningAgreementRefType">
            <xs:attribute name="governingAgreementRef"
              type="xs:anyURI"
              fixed="https://foo.example.com/assurance/"
              use="required"/>
            </xs:restriction>
        </xs:complexContent>
      </xs:complexType>
  </xs:redefine>
</xs:schema>

3.2. Note on the Example 🙈

The example is borrowed (and slightly modified) from [SAML]. The example should not be registered ❌.

Part 2 is coming next, bestie, with Section 4 (Registration Policy) and everything after it 💜✨

7. Security Considerations ✨

okay bestie, this section is short but it's giving very important energy 🫶 The registry is NOT a federation or trust framework 🚫 🍓 So if you're a consumer of this registry, you are strongly advised to take a good, careful look at the information about an LoA (level of assurance) before you rely on it. Trust me, you do not want to just vibe with it blindly 💀

8. Acknowledgements 🎀

shoutout to RL "Bob" Morgan, Scott Cantor, Lucy Lynch, and John Bradley 💜 They were involved in the very first discussions around this idea and helped shape the semantics of the registry. The different versions of the document got socialized in the Kantara Federation Interoperability WG and in other parts of the identity community too 🌸 Iconic teamwork, periodt 👑

9. References 📚

9.1. Normative References

These are the must-read ones, bestie 🦋

9.2. Informative References

These ones are more like extra reading for the curious 🧚

  • [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [SP63] NIST, "Electronic Authentication Guideline, NIST Special Publication 800-63", June 2004.

Author's Address

Leif Johansson NORDUNet Tulegatan 11 Stockholm Sweden

EMail: leifj@nordu.net

That's the whole RFC, bestie! 🌈 Now you know the registry isn't a trust framework, so go be a careful consumer 💅✨

📦 where this page comes from