+ 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. +
++ 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. +
++ 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]] +
++ 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> ++
+ 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]]. +
+
+ 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.
+
+ 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]]. +
++ This document defines an authentication suite for the Linked Web Storage (LWS) protocol, enabling clients that are able to sign their own identity tokens to integrate with LWS. +
++ This is an unofficial proposal. +
++ Self-issued identity is important for cases where applications act on their own behalf. This includes autonomous bots as well as server-side scripts, among others. + In these cases, the agent is able to securely manage the private portion of a keypair, which it uses to generate signed JSON Web Tokens (JWT). + This specification describes how this class of agents can generate end-user credentials that can be used with a Linked Web Storage. +
++ The terms "authorization server" and "client" are defined by The OAuth 2.0 Authorization Framework [[!RFC6749]]. +
+ ++ The terms "controlled identifier document" and "verification method" are defined by W3C Controlled Identifiers 1.0 [[!CID-1.0]]. +
+ ++ The terms "JSON Web Token (JWT)" and "claim" are defined by JSON Web Token [[!RFC7519]]. +
+ ++ The terms "end-user credential" and "authentication suite" are defined by Linked Web Storage Protocol [[!LWS-PROTOCOL]] +
++ A self-issued end-user credential is serialized as a signed JSON Web Token (JWT). In order to use a JWT as an LWS end-user credential, the following additional requirements apply. +
+ ++ The JWT MUST NOT use "none" as the signing algorithm. +
+ +
+ The JWT MUST use the sub (subject) claim for the LWS subject identifier.
+
+ The JWT MUST use the iss (issuer) claim for the LWS issuer identifier.
+
+ The JWT MUST use the client_id (client ID) claim for the LWS client identifier.
+
+ The claims sub, iss, and client_id MUST all use the same URI value.
+
+ Any audience restriction in the ID Token MUST use the aud (audience) claim. The aud claim MUST include the target authorization server.
+
+ The JWT MUST include an exp (expiration) claim, indicating the time the token expires.
+
+ The JWT MUST include an iat (issued at) claim, indicating the time the token was issued.
+
+ An example JWT that is also an LWS end-user credential is included below. +
+ +
+{
+ "kid": "c1f52577",
+ "kty": "EC",
+ "alg": "ES256",
+ "typ": "JWT",
+ "crv": "P-256"
+}
+.
+{
+ "sub": "https://id.example/agent",
+ "iss": "https://id.example/agent",
+ "client_id": "https://id.example/agent",
+ "aud": ["https://as.example"],
+ "iat": 1761313600,
+ "exp": 1761313900
+}
+.
+signature
+
+ + In order to validate a JWT as an LWS end-user credential, there must be a trust relationship between the verifier and the issuing party. +
+ +
+ In the absence of a pre-existing trust relationship, the verifier MUST dereference the sub (subject) claim in the end-user credential.
+ The resulting resource MUST be formatted as a valid controlled identifier document [[!CID-1.0]] with an id value equal to the subject identifier.
+
+ A verifier MUST reject any tokens using an alg header parameter that equals "none".
+
+ A verifier MUST validate all claims described by the end-user credential data model. +
+ +
+ The verifier MUST use the kid (key id) value from the signed JWT header to identify a verification method from the subject's controlled identifier document.
+ This process is described in [[!CID-1.0]] Section 3.3.
+ Using the selected verification method from the controlled identifier document, the signature of the JWT MUST be validated as described in [[!RFC7515]], Section 5.2.
+
+ A verifier MUST ensure that the current time is before the time represented by the exp claim. Implementers MAY provide for some small leeway to account for clock skew.
+
+ An example Controlled Identifier Document is included below. +
+ +
+{
+ "@context": [
+ "https://www.w3.org/ns/cid/v1" ],
+ "id": "https://id.example/agent",
+ "authentication": [{
+ "id": "https://id.example/agent#c1f52577",
+ "type": "JsonWebKey",
+ "controller": "https://id.example/agent",
+ "publicKeyJwk": {
+ "kid": "c1f52577",
+ "kty": "EC",
+ "crv": "P-256",
+ "alg": "ES256",
+ "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
+ "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
+ }
+ }]
+}
+
+
+ A self-issued JSON Web Token used as an end-user credential MUST use the urn:ietf:params:oauth:token-type:jwt URI when interacting with an authorization server.
+
+ All security considerations described in "Best Current Practice for OAuth 2.0 Security" [[RFC9700]] and "OpenID Connect Core 1.0" Section 16 [[OPENID-CONNECT-CORE]] apply to this specification. +
++ This document defines an authentication suite for the Linked Web Storage (LWS) protocol, enabling clients that are able to sign their own identity tokens to integrate with LWS. +
++ This is an unofficial proposal. +
++ Self-issued identity is important for cases where applications act on their own behalf. + This includes autonomous bots as well as server-side scripts, among others. + In these cases, the agent is able to securely manage the private portion of a keypair, which it uses to generate signed JSON Web Tokens (JWT). + This specification describes how this class of agents can generate end-user credentials that can be used with a Linked Web Storage while using agent identifers with the `did:key:` method. +
++ The terms "authorization server" and "client" are defined by The OAuth 2.0 Authorization Framework [[!RFC6749]]. +
+ ++ The terms "JSON Web Token (JWT)" and "claim" are defined by JSON Web Token [[!RFC7519]]. +
+ ++ The terms "end-user credential" and "authentication suite" are defined by Linked Web Storage Protocol [[!LWS-PROTOCOL]] +
++ A self-issued end-user credential is serialized as a signed JSON Web Token (JWT). In order to use a JWT as an LWS end-user credential, the following additional requirements apply. +
+ +sub (subject) claim for the LWS subject identifier. The subject identifier MUST use a did:key: URI.
+ iss (issuer) claim for the LWS issuer identifier.
+ client_id (client ID) claim for the LWS client identifier.
+ sub, iss, and client_id MUST all use the same URI value.
+ aud (audience) claim. The aud claim MUST include the target authorization server.
+ exp (expiration) claim, indicating the time the token expires.
+ iat (issued at) claim, indicating the time the token was issued.
+ + An example JWT that is also an LWS end-user credential is included below. +
+ +
+{
+ "kty": "EC",
+ "alg": "ES256",
+ "typ": "JWT",
+ "crv": "P-256"
+}
+.
+{
+ "sub": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
+ "iss": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
+ "client_id": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
+ "aud": ["https://as.example"],
+ "iat": 1761313600,
+ "exp": 1761313900
+}
+.
+signature
+
+
+ For subject identifiers that use the did:key method, a verifier will extract a public key from the identifier itself, as described in Section 3.1.3 of "The did:key Method" [[did-key]]. Using this public key, the signature of the JWT MUST be validated as described in [[!RFC7515]], Section 5.2.
+
+ A verifier MUST validate all claims described by the end-user credential data model. +
+ +
+ A verifier MUST ensure that the current time is before the time represented by the exp claim. Implementers MAY provide for some small leeway to account for clock skew.
+
+ A self-issued JSON Web Token used as an end-user credential MUST use the urn:ietf:params:oauth:token-type:jwt URI when interacting with an authorization server.
+
+ All security considerations described in "Best Current Practice for OAuth 2.0 Security" [[RFC9700]] and "OpenID Connect Core 1.0" Section 16 [[OPENID-CONNECT-CORE]] apply to this specification. +
++ This section defines a mechanism for identifying agents and end users that interact + with a linked web storage server. This specification does not mandate a particular + format for end-user credentials, though it does describe how existing identity systems + can be used in conjunction with the linked web storage authorization framework. +
+ ++ The data model described in this section outlines the requirements for any + concrete serialization of an end-user credential. +
+ ++ An end-user credential MUST include tamper evident claims about a subject, including: +
+ ++ Validation of an end-user credential requires a trust relationship between the + verifier and issuer of the credential. This trust relationship MAY be established + through an out-of-band mechanism. Any additional mechanisms for establishing trust + between a verifier and an issuer are outlined in specific authentication suites. +
+ ++ An end-user credential MUST be signed. It is RECOMMENDED that the signature uses asymmetric cryptography. +
++ Each authentication suite MUST be associated with a token type URI. An authentication suite SHOULD use a URI defined in the IANA "OAuth URI" registry. +
++ End-user credentials carry information about users. While digital signatures can protect end-user credentials against tampering, it is possible for clients or other third parties to read the values inside an unencrypted credential. +
+ ++ As a result, issuers should create end-user credentials that contain only the information necessary for authentication. Avoid including sensitive attributes unless required. +
+ ++ Implementations should not log the full contents of an end-user credential. If logging is necessary, tokens should be truncated or hashed. +
++ All communications related to requesting, retrieving and presenting end-user credentials between clients and servers must use TLS-protected connections. +
+ ++End-user credentials are vulnerable to theft and replay. Tokens should have a reasonably short lifetime, such as 3600 seconds (1 hour). +
+ ++Clients that persist end-user credentials must take great care to store these tokens securely. Tokens should never be stored unencrypted in a browser's localStorage, in URLs or in logs. +
++ The terms "authorization server" and "client" are defined by the OAuth 2.0 Authorization Framework [[!RFC6749]]. +
+
+ The terms "end-user" and "issuer" are defined by OpenID Connect Core 1.0 [[!OPENID-CONNECT-CORE]]. +
+ ++ This specificaiton defines the following terms: +
+This specification defines operations on served resources, the resulting change of state, and a response indended to give the requesting agent requested infomation or inform them of the outcome of the operation. An operation is any of the following actions that can be performed on a served resource: @@ -176,27 +191,7 @@
- For any access control that requires establishing the identity of a requesting agent, that identiy is established using strawman-authn: -
-
- {
- "@context": ["https://strawman-authn"],
- "client_id": "https://app.example/id",
- "client_name": "Solid Application Name",
- "redirect_uris": ["https://app.example/callback"],
- "post_logout_redirect_uris": ["https://app.example/logout"],
- "client_uri": "https://app.example/",
- "logo_uri" : "https://app.example/logo.png",
- "tos_uri" : "https://app.example/tos.html",
- "scope" : "openid profile offline_access webid",
- "grant_types" : ["refresh_token","authorization_code"],
- "response_types" : ["code"],
- "default_max_age" : 3600,
- "require_auth_time" : true
- }
-
-
+