Internet-Draft SCRAPI March 2024
Birkholz, et al. Expires 5 September 2024 [Page]
Workgroup:
SCITT
Internet-Draft:
draft-ietf-scitt-scrapi-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
H. Birkholz
Fraunhofer SIT
O. Steele
Transmute
J. Geater
DataTrails Inc.

SCITT Reference APIs

Abstract

This document describes a REST API that supports the normative requirements of the SCITT Architecture [I-D.draft-ietf-scitt-architecture]. Optional key discovery and query interfaces are provided to support interoperability issues with Decentralized Identifiers, X509 Certificates and Artifact Reposistories.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/.

Discussion of this document takes place on the SCITT Working Group mailing list (mailto:scitt@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scitt/. Subscribe at https://www.ietf.org/mailman/listinfo/scitt/.

Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-scitt/draft-ietf-scitt-scrapi.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 September 2024.

▲

Table of Contents

1. Introduction

The SCITT Architecture [I-D.draft-ietf-scitt-architecture] defines the core operations necessary to support supply chain transparency using COSE (CBOR Object Signing and Encryption).

In addition to defining concrete HTTP endpoints for these operations, this specification defines support for the following endpoints which support these operations:

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 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.

This specification uses the terms "Signed Statement", "Receipt", "Transparent Statement", "Artifact Repositories", "Transparency Service", "Append-Only Log" and "Registration Policy" as defined in [I-D.draft-ietf-scitt-architecture].

This specification uses "payload" as defined in [RFC9052].

2. Endpoints

Authentication is out of scope for this document. If Authentication is not implemented, rate limiting or other denial of service mititations MUST be applied to enable anonymous access.

NOTE: '' line wrapping per RFC 8792 in HTTP examples.

All messages are sent as HTTP GET or POST requests.

If the Transparency Service cannot process a client's request, it MUST return an HTTP 4xx or 5xx status code, and the body SHOULD be a JSON problem details object ([RFC7807]) containing:

Error responses SHOULD be sent with the Content-Type: application/problem+json HTTP header.

As an example, submitting a Signed Statement with an unsupported signature algorithm would return a 400 Bad Request status code and the following body:

{
  "type": "urn:ietf:params:scitt:error:badSignatureAlgorithm",
  "detail": "Signing algorithm not support"
}

Most error types are specific to the type of request and are defined in the respective subsections below. The one exception is the "malformed" error type, which indicates that the Transparency Service could not parse the client's request because it did not comply with this document:

Clients SHOULD treat 500 and 503 HTTP status code responses as transient failures and MAY retry the same request without modification at a later date. Note that in the case of a 503 response, the Transparency Service MAY include a Retry-After header field per [RFC7231] in order to request a minimum time for the client to wait before retrying the request. In the absence of this header field, this document does not specify a minimum.

2.1. Mandatory

The following HTTP endpoints are mandatory to implement to enable conformance to this specification.

2.1.1. Transparency Configuration

Authentication SHOULD NOT be implemented for this endpoint. This endpoint is used to discovery the capabilites of a transparency service implementing this specification.

Request:

GET /.well-known/transparency-configuration HTTP/1.1
Host: transparency.example
Accept: application/json

Response:

HTTP/1.1 200 Ok
Content-Type: application/json

{
  "issuer": "https://transparency.example",
  "registration_endpoint": "https://transparency.example/entries",
  "nonce_endpoint": "https://transparency.example/nonce",

  "registration_policy": \
"https://transparency.example\
/statements/urn:ietf:params:scitt:statement\
:sha-256:base64url:5i6UeRzg1...qnGmr1o",

  "supported_signature_algorithms": ["ES256"],
  "jwks": {
    "keys": [
      {
        "kid": "urn:ietf:params:oauth:\
jwk-thumbprint:sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
        "alg": "ES256",
        "use": "sig",
        "kty": "EC",
        "crv": "P-256",
        "x": "p-kZ4uOASt9IjQRTrWikGnlbGb-z3LU1ltwRjZaOS9w",
        "y": "ymXE1yltJPXgjQSRe9NweN3TLlSUALYZTzy83NVfdg0"
      },
      {
        "kid": "urn:ietf:params:oauth:\
jwk-thumbprint:sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
        "alg": "HPKE-Base-P256-SHA256-AES128GCM",
        "use": "enc",
        "kty": "EC",
        "crv": "P-256",
        "x": "Vreuil95vzR6ixutgBBf2ota-rj97MvKfuJWB4qqp5w",
        "y": "NkUTeaoNlLRRsVRxHGDA-RsA0ex2tSpcd3G-4SmKXbs"
      }
    ]
  }
}

Additional fields may be present. Fields that are not understood MUST be ignored.

2.1.2. Signed Statement Registration

Authentication MUST be implemented for this endpoint.

The following is a non-normative example of a HTTP request to register a Signed Statement:

Request:

POST /entries HTTP/1.1
Host: transparency.example
Accept: application/json
Content-Type: application/cose
Payload (in CBOR diagnostic notation)

18([                            / COSE Sign1         /
  h'a1013822',                  / Protected Header   /
  {},                           / Unprotected Header /
  null,                         / Detached Payload   /
  h'269cd68f4211dffc...0dcb29c' / Signature          /
])

The Registration Policy for the Transparency Service MUST be applied to the payload bytes, before any additional processing is performed.

If the payload is detached, the Transparency Service depends on the authentication context of the client in the Registration Policy. If the payload is attached, the Transparency Service depends on both the authentication context of the client, and the verification of the Signed Statement in the Registration Policy. The details of Registration Policy are out of scope for this document.

If registration succeeds the following identifier MAY be used to refer to the Signed Statement that was accepted:

urn:ietf:params:scitt:signed-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

If the payload was attached, or otherwise communicated to the Transparency Service, the following identifier MAY be used to refer to the payload of the Signed Statement:

urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

Response:

One of the following:

2.1.2.1. Status 201 - Registration is successful 
HTTP/1.1 201 Ok

Location: https://transparency.example/receipts\
/urn:ietf:params:scitt:signed-statement\
:sha-256:base64url:5i6UeRzg1...qnGmr1o

Content-Type: application/cose

Payload (in CBOR diagnostic notation)

18([                            / COSE Sign1         /
  h'a1013822',                  / Protected Header   /
  {},                           / Unprotected Header /
  null,                         / Detached Payload   /
  h'269cd68f4211dffc...0dcb29c' / Signature          /
])

The response contains the Receipt for the Signed Statement. Fresh receipts may be requested through the resource identified in the Location header.

2.1.2.2. Status 202 - Registration is running 
HTTP/1.1 202 Ok

Location: https://transparency.example/receipts\
/urn:ietf:params:scitt:signed-statement\
:sha-256:base64url:5i6UeRzg1...qnGmr1o

Content-Type: application/json
Retry-After: <seconds>

{

  "receipt": "urn:ietf:params:scitt:receipt\
:sha-256:base64url:5i6UeRzg1...qnGmr1o",

}

The response contains a reference to the receipt which will eventually be available for the Signed Statement.

If 202 is returned, then clients should wait until Registration succeeded or failed by polling the receipt endpoint using the receipt identifier returned in the response.

2.1.2.3. Status 400 - Invalid Client Request

One of the following errors:

{
  "type": "urn:ietf:params:scitt:error\
:signed-statement:algorithm-not-supported",
  "detail": \
"Signed Statement contained an algorithm that is not supported."
}

{
  "type": "urn:ietf:params:scitt:error\
:signed-statement:payload-missing",
  "detail": \
"Signed Statement payload must be attached (must be present)"
}

{
  "type": "urn:ietf:params:scitt:error\
:signed-statement:payload-forbidden",
  "detail": \
"Signed Statement payload must be detached (must not be present)"
}

{
  "type": "urn:ietf:params:scitt:error\
:signed-statement:rejected-by-registration-policy",
  "detail": \
"Signed Statement was not accepted by the current Registration Policy"
}

{
  "type": "urn:ietf:params:scitt:error\
:signed-statement:confirmation-missing",
  "detail": \
"Signed Statement did not contain proof of possession"
}

TODO: other error codes

2.2. Optional Endpoints

The following HTTP endpoints are optional to implement.

2.2.1. Issue Statement

Authentication MUST be implemented for this endpoint.

This endpoint enables a Transparency Service to be an issuer of Signed Statements on behalf of authenticated clients. This supports cases where a client lacks the ability to perform complex cryptographic operations, but can be authenticated and report statements and measurements.

Request:

POST /signed-statements/issue HTTP/1.1
Host: transparency.example
Accept: application/json
Content-Type: application/vc+ld+json
Payload

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://transparency.example/credentials/1872",
  "type": ["VerifiableCredential", "SensorCredential"],
  "issuer": "https://transparency.example/device/1234",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "type": "Feature",
    "geometry": {
      "type": "Point",
      "coordinates": [125.6, 10.1]
    },
    "properties": {
      "name": "Dinagat Islands"
    }
  }
}

Response:

HTTP/1.1 200 Ok
Content-Type: application/cose

Payload (in CBOR diagnostic notation)

18([                            / COSE Sign1         /
  h'a1013822',                  / Protected Header   /
  {},                           / Unprotected Header /
  null,                         / Detached Payload   /
  h'269cd68f4211dffc...0dcb29c' / Signature          /
])

2.2.2. Resolve Statement

Authentication SHOULD be implemented for this endpoint.

This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve payload values directly, instead of indirectly through Receipts.

Request:

GET /statements/urn...qnGmr1o HTTP/1.1
Host: transparency.example
Accept: application/pdf

Response:

HTTP/1.1 200 Ok
Content-Type: application/pdf
Payload (pdf bytes)

2.2.3. Resolve Signed Statement

Authentication SHOULD be implemented for this endpoint.

This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts.

Request:

GET /signed-statements/urn...qnGmr1o HTTP/1.1
Host: transparency.example
Accept: application/cose

Response:

HTTP/1.1 200 Ok
Content-Type: application/cose

Payload (in CBOR diagnostic notation)

18([                            / COSE Sign1         /
  h'a1013822',                  / Protected Header   /
  {},                           / Unprotected Header /
  null,                         / Detached Payload   /
  h'269cd68f4211dffc...0dcb29c' / Signature          /
])

2.2.4. Resolve Receipt

Authentication SHOULD be implemented for this endpoint.

Request:

GET /receipts/urn...qnGmr1o HTTP/1.1
Host: transparency.example
Accept: application/cose

Response:

If the Signed Statement requested is already included in the Append-Only Log:

HTTP/1.1 200 Ok
Location: https://transparency.example/receipts/urn...qnGmr1o
Content-Type: application/cose

Payload (in CBOR diagnostic notation)

18([                            / COSE Sign1         /
  h'a1013822',                  / Protected Header   /
  {},                           / Unprotected Header /
  null,                         / Detached Payload   /
  h'269cd68f4211dffc...0dcb29c' / Signature          /
])

If the Signed Statement requested is not yet included in the Append-Only Log:

HTTP/1.1 202 Ok
Location: https://transparency.example/receipts/urn...qnGmr1o
Content-Type: application/json
Retry-After: <seconds>

{
  "receipt": "urn:ietf:params:scitt:receipt\
    :sha-256:base64url:5i6UeRzg1...qnGmr1o",
}

Additional eventually consistent operation details MAY be present. Support for eventually consistent Receipts is implementation specific, and out of scope for this specification.

2.2.5. Resolve Issuer

This endpoint is inspired by [I-D.draft-ietf-oauth-sd-jwt-vc]. Authentication SHOULD NOT be implemented for this endpoint. This endpoint is used to discover verification keys, which is the reason that authentication is not required.

The following is a non-normative example of a HTTP request for the Issuer Metadata configuration when iss is set to https://transparency.example/tenant/1234:

Request:

GET /.well-known/issuer/tenant/1234 HTTP/1.1
Host: transparency.example
Accept: application/json

Response:

HTTP/1.1 200 Ok
Content-Type: application/json

{
  "issuer": "https://transparency.example/tenant/1234",
  "jwks": {
    "keys": [
      {
        "kid": "urn:ietf:params:oauth\
:jwk-thumbprint:sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
        "alg": "ES256",
        "use": "sig",
        "kty": "EC",
        "crv": "P-256",
        "x": "p-kZ4uOASt9IjQRTrWikGnlbGb-z3LU1ltwRjZaOS9w",
        "y": "ymXE1yltJPXgjQSRe9NweN3TLlSUALYZTzy83NVfdg0"
      },
      {
        "kid": "urn:ietf:params:oauth\
:jwk-thumbprint:sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
        "alg": "HPKE-Base-P256-SHA256-AES128GCM",
        "use": "enc",
        "kty": "EC",
        "crv": "P-256",
        "x": "Vreuil95vzR6ixutgBBf2ota-rj97MvKfuJWB4qqp5w",
        "y": "NkUTeaoNlLRRsVRxHGDA-RsA0ex2tSpcd3G-4SmKXbs"
      }
    ]
  }
}

2.2.6. Request Nonce

This endpoint in inspired by [I-D.draft-demarco-oauth-nonce-endpoint].

Authentication SHOULD NOT be implemented for this endpoint. This endpoint is used to demonstrate proof of posession, which is the reason that authentication is not required. Client holding signed statements that require demonstrating proof of possession MUST use this endpoint to obtain a nonce.

Request:

GET /nonce HTTP/1.1
Host: transparency.example
Accept: application/json

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
}

2.2.7. Resolve Issuer DID

This endpoint enables the use of the DID Web Decentralized Identifier Method, as an alternative expression of the Issuer Metadata endpoint.

This endpoint is DEPRECATED.

The following is a non-normative example of a HTTP request for the Issuer Metadata configuration when iss is set to did:web:transparency.example:tenant:1234:

Request:

GET /tenant/1234/did.json HTTP/1.1
Host: transparency.example
Accept: application/did+ld+json

Response:

HTTP/1.1 200 Ok
Content-Type: application/did+ld+json

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    {
      "@vocab": "https://vocab.transparency.example#"
    }
  ],
  "id": "did:web:transparency.example:tenant:1234",
  "verificationMethod": [
    {
      "id": "did:web:transparency.example:tenant:1234\
        #urn:ietf:params:oauth:jwk-thumbprint\
        :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",
      "type": "JsonWebKey",
      "controller": "did:web:transparency.example:tenant:1234",
      "publicKeyJwk": {
        "kid": "urn:ietf:params:oauth:jwk-thumbprint\
          :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",
        "alg": "ES256",
        "use": "sig",
        "kty": "EC",
        "crv": "P-256",
        "x": "9ptuW0PBHSTN7bVexWd7xM5kmSPGRaCu-K3SLtJyvNc",
        "y": "l7NvF6QbovicSciZqu_W_xy4JTZwtnUbn2SNdMKoaAk"
      }
    },
    {
      "id": "did:web:transparency.example:tenant:1234\
        #urn:ietf:params:oauth:jwk-thumbprint\
        :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
      "type": "JsonWebKey",
      "controller": "did:web:transparency.example:tenant:1234",
      "publicKeyJwk": {
        "kid": "urn:ietf:params:oauth:jwk-thumbprint\
          :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
        "alg": "ES256",
        "use": "sig",
        "kty": "EC",
        "crv": "P-256",
        "x": "p-kZ4uOASt9IjQRTrWikGnlbGb-z3LU1ltwRjZaOS9w",
        "y": "ymXE1yltJPXgjQSRe9NweN3TLlSUALYZTzy83NVfdg0"
      }
    },
    {
      "id": "did:web:transparency.example:tenant:1234\
        #urn:ietf:params:oauth:jwk-thumbprint\
        :sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
      "type": "JsonWebKey",
      "controller": "did:web:transparency.example:tenant:1234",
      "publicKeyJwk": {
        "kid": "urn:ietf:params:oauth:jwk-thumbprint\
          :sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
        "alg": "HPKE-Base-P256-SHA256-AES128GCM",
        "use": "enc",
        "kty": "EC",
        "crv": "P-256",
        "x": "Vreuil95vzR6ixutgBBf2ota-rj97MvKfuJWB4qqp5w",
        "y": "NkUTeaoNlLRRsVRxHGDA-RsA0ex2tSpcd3G-4SmKXbs"
      }
    }
  ],
  "assertionMethod": [
    "did:web:transparency.example:tenant:1234\
      #urn:ietf:params:oauth:jwk-thumbprint\
      :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",
    "did:web:transparency.example:tenant:1234\
      #urn:ietf:params:oauth:jwk-thumbprint\
      :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo"
  ],
  "authentication": [
    "did:web:transparency.example:tenant:1234\
      #urn:ietf:params:oauth:jwk-thumbprint\
      :sha-256:5b30k1hBWBMcggA9GIJImUqj4pXqrJ9EOWV6MDdcstA",
    "did:web:transparency.example:tenant:1234\
      #urn:ietf:params:oauth:jwk-thumbprint\
      :sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo"
  ],
  "keyAgreement": [
    "did:web:transparency.example:tenant:1234\
      #urn:ietf:params:oauth:jwk-thumbprint\
      :sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE"
  ]
}

3. Privacy Considerations

TODO

4. Security Considerations

TODO

TODO: Consider negotiation for receipt as "JSON" or "YAML". TODO: Consider impact of media type on "Data URIs" and QR Codes.

5. IANA Considerations

5.1. URN Sub-namespace for SCITT (urn:ietf:params:scitt)

IANA is requested to register the URN sub-namespace urn:ietf:params:scitt in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" Registry [IANA.params], following the template in [RFC3553]:

   Registry name:  scitt
   Specification:  [RFCthis]
   Repository:  http://www.iana.org/assignments/scitt
   Index value:  No transformation needed.

5.2. Well-Known URI for Issuers

The following value is requested to be registered in the "Well-Known URIs" registry (using the template from [RFC5785]):

URI suffix: issuer Change controller: IETF Specification document(s): RFCthis. Related information: N/A

5.3. Well-Known URI for Transparency Configuration

The following value is requested to be registered in the "Well-Known URIs" registry (using the template from [RFC5785]):

URI suffix: transparency-configuration Change controller: IETF Specification document(s): RFCthis. Related information: N/A

TODO: Register them from here.

5.4. Media Type Registration

This section requests registration of the "application/scitt.receipt+cose" media type [RFC2046] in the "Media Types" registry in the manner described in [RFC6838].

To indicate that the content is a SCITT Receipt:

  • Type name: application

  • Subtype name: scitt.receipt+cose

  • Required parameters: n/a

  • Optional parameters: n/a

  • Encoding considerations: TODO

  • Security considerations: TODO

  • Interoperability considerations: n/a

  • Published specification: this specification

  • Applications that use this media type: TBD

  • Fragment identifier considerations: n/a

  • Additional information:

    • Magic number(s): n/a

    • File extension(s): n/a

    • Macintosh file type code(s): n/a

  • Person & email address to contact for further information: TODO

  • Intended usage: COMMON

  • Restrictions on usage: none

  • Author: TODO

  • Change Controller: IESG

  • Provisional registration? No

6. References

6.1. Normative References

[I-D.draft-ietf-scitt-architecture]
Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-05>.
[IANA.params]
IANA, "Uniform Resource Name (URN) Namespace for IETF Use", <http://www.iana.org/assignments/params>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3553]
Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, , <https://www.rfc-editor.org/rfc/rfc3553>.
[RFC5785]
Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, , <https://www.rfc-editor.org/rfc/rfc5785>.
[RFC7231]
Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, , <https://www.rfc-editor.org/rfc/rfc7231>.
[RFC7807]
Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, , <https://www.rfc-editor.org/rfc/rfc7807>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.

6.2. Informative References

[I-D.draft-demarco-oauth-nonce-endpoint]
De Marco, G. and O. Steele, "OAuth 2.0 Nonce Endpoint", Work in Progress, Internet-Draft, draft-demarco-oauth-nonce-endpoint-00, , <https://datatracker.ietf.org/doc/html/draft-demarco-oauth-nonce-endpoint-00>.
[I-D.draft-ietf-oauth-sd-jwt-vc]
Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-02>.
[RFC2046]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, , <https://www.rfc-editor.org/rfc/rfc2046>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/rfc/rfc6838>.

Authors' Addresses

Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Orie Steele
Transmute
Jon Geater
DataTrails Inc.
United States