This document defines a SAML-based authentication suite for the Linked Web Storage (LWS) protocol, enabling LWS applications to integrate with SAML 2.0 identity providers.

This is an unofficial proposal.

Introduction

The Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization assertions between parties, typically between web-based service providers (i.e., an application) and identity providers. These assertions are encoded in an XML format containing a digital signature. This specification describes how SAML-based identity tokens can be used to authenticate end users in a Linked Web Storage environment.

Terminology

The terms "authorization server" and "client" are defined by The OAuth 2.0 Authorization Framework [[!RFC6749]].

The terms "identity provider" and "assertion" are defined by The Security Assertion Markup Language (SAML) 2.0 [[!SAML2-CORE]].

The terms "authentication credential" and "authentication suite" are defined by Linked Web Storage Protocol [[!LWS10-CORE]]

Authentication Credential Serialization

SAML tokens used as authentication credentials MUST be signed. In addition, a valid SAML token MUST include the following assertions:

The SAML token MUST use the saml:NameID assertion for the LWS subject identifier.

The SAML token MUST use the saml:Issuer assertion for the LWS issuer identifier.

The SAML token MUST use the Recipient parameter within a saml:SubjectConfirmationData assertion for the LWS client identifier.

Any audience restriction in the SAML token MUST use the saml:Audience assertion. The saml:Audience assertion SHOULD include a client identifier and any additional target audience such as an authorization server.

An example SAML Authentication Credential is included below. 

<samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    Version="2.0"
    IssueInstant="2025-10-25T01:01:16Z">

  <saml:Issuer>https://idp.example

  <ds:Signature>
    <ds:SignedInfo>
      ...
    <ds:SignedInfo>
  <ds:SignedInfo>

  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  <samlp:Status>

  <saml:Assertion Version="2.0" IssueInstant="2025-10-25T01:01:16Z">
    <saml:Issuer>https://idp.example</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
          https://id.example/end-user
      <saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2025-10-25T02:01:16Z"
                                      Recipient="https://app.example/SAML"/>
      <saml:SubjectConfirmation>
    <saml:Subject>
    <saml:Conditions NotBefore="2025-10-25T01:01:16Z"
                     NotOnOrAfter="2025-10-25T02:01:16Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://app.example/SAML
        <saml:Audience>https://as.example
      <saml:AudienceRestriction>
    <saml:Conditions>
  <saml:Assertion>
<samlp:Response>

Authentication Credential Validation

In order to validate a SAML authentication credential, there must be a trust relationship with the issuing identity provider. This specification does not define how a validating entity establishes a trust relationship with an identity provider, expecting these relationships to be established out-of-band.

Using a trust relationship with an issuer, the signature of the credential MUST be validated as described in SAML Core, section 5 [[!SAML2-CORE]].

Token Type Identifier

A SAML 2.0 assertion used as an authentication credential MUST use the urn:ietf:params:oauth:token-type:saml2 URI when interacting with an authorization server.

Security Considerations

All security considerations described in "[[[SAML2-SEC]]]" [[SAML2-SEC]] apply to this specification.

A SAML identity provider should support a mechanism to restrict the audience of an authentication credential to a limited set of entities, including an authorization server. A client in possession of an authentication credential with no audience restrictions should exchange this token for an equivalent audience-restricted token by using, for example, OAuth 2.0 Token Exchange [[RFC8693]].

Privacy Considerations

All privacy considerations described in "[[[SAML2-SEC]]]" [[SAML2-SEC]] apply to this specification.

A SAML assertion used as an authentication credential can contain attributes that reveal personally identifiable information about the end-user. Identity providers are encouraged to issue assertions that contain only the information necessary for LWS authentication — specifically, the saml:NameID, saml:Issuer, and saml:Audience elements and the Recipient attribute of saml:SubjectConfirmationData — and to avoid including additional identity attributes unless explicitly required.

The saml:NameID element is used as the LWS subject identifier. When a persistent name identifier format is used, it enables verifiers and storage servers to correlate an end-user's activity across sessions and resources. Identity providers that support transient name identifiers can reduce this correlation, though deployers will need to evaluate whether transient identifiers are compatible with the access control requirements of their LWS deployment.

The trust model for SAML in this specification relies on out-of-band trust establishment with identity providers. This means there is no subject identifier dereference step during validation, which avoids the associated metadata leakage. However, the out-of-band trust relationship itself reveals which identity providers are used within a deployment.

SAML assertions presented to a storage server or authorization server can be read by those parties. Audience restriction (via the saml:AudienceRestriction element) limits which parties the assertion is intended for but does not prevent an intermediary from reading the assertion's contents in transit. The use of TLS is essential for protecting authentication credentials during transmission.