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 "end-user credential" and "authentication suite" are defined by Linked Web Storage Protocol [[!LWS-PROTOCOL]]

End-User Credential Serialization

SAML tokens used as end-user 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 End-User 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>

End-User Credential Validation

In order to validate a SAML end-user 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 end-user 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 "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0" apply to this specification.

A SAML identity provider should support a mechanism to restrict the audience of an end-user credential to a limited set of entities, including an authorization server. A client in possession of an end-user 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]].