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.
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
Publication as a First Public Working Draft does not
imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than a work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
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.
2. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST and SHOULD in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all
capitals, as shown here.
3. 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 [LWS-PROTOCOL]
4. 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.
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].
6. 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.
7. Security Considerations
This section is non-normative.
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 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].
8. Privacy Considerations
This section is non-normative.
Issue 119: Add Privacy Considerations sections to the authentication suites