Attestation in OpenID-Connect

2.1. Terminology

This specification uses role names as defined by Remote ATtestation procedureS (RATS), [RFC9334] and OpenID Connect (OIDC), [OCC2014]. If role names conflict, (e.g., Relying Party), then the RATS role is qualified by prepending ‘RATS’ or ‘R’. For example, the RATS Relying Party is disambiguated as ‘RRP’.¶

A summary of roles used in this specification is provided here for convenience.¶

RATS roles are as follows:¶

• Attester (RA) - an endpoint that produces attestation Evidence.¶
• Reference Value Provider (RVP) - an endpoint that produces Reference Values used to appraise Evidence.¶
• Endorser (RE) - an endpoint that produces Endorsements used to assess the trustworthiness of the Attester's attestation capability.¶
• Verifier (RV) - an endpoint that consumes Evidence, Endorsements and Reference Values and produces Attestation Results.¶
• Relying Party (RRP) - an endpoint that consumes Attestation Results and applies them to an application or usage context.¶

OIDC roles are as follows:¶

• OpenID Provider (OP) - an endpoint that authenticates an End User, obtains authorization, and responds with an ID Token and (usually) an Access Token. (a.k.a., an OAuth 2.0 Authorization Server, [RFC6749]).¶
• Relying Party (RP) / Client - an endpoint that sends a request to an OpenID Provider.¶
• UserInfo Endpoint (UE) - an API endpoint that receives an Access Token and sends Claims about an End User.¶
• User Agent (UA) - a browser or other code that may interact with an End User or access user resources.¶
• End User (EU) - a human participant.¶

OAuth 2.0 roles are as follows:¶

• Resource Server (RS) - a service that controls a resource.¶
• Client - synonymous with User Agent.¶
• Resource Owner (RO) - synonymous with End User.¶

3.1. Protocol Endpoints

The example protocol message exchange involves four main endpoints:¶

1. Device - a RATS Attester that consists of two sub entities:¶

• A UserInfo Endpoint (UE) that supplies user information for OIDC authentication, and¶
• A lead Attesting Environment, that collects device attestation Evidence. When using RATS terminology, the device may be referred to as the RATS Attester (RA). The RA is technically an OAuth 2.0 Resource Server (RS) that performs attestation Evidence collection. The Attester device may consist of multiple components that typically include a root of trust, boot code, system software and the browser. The lead Attesting Environment typically seeks to collect Evidence that describes all the components, from the root of trust to the UA, that may influence endpoint behavior.¶

2. User Agent (UA) - a native application that can engage the End User directly.¶
3. Relying Party (RP) - an endpoint that seeks UserInfo used to replay user authentication responses for OIDC exchanges. The RP may rely on the OP to appraise attestation results on its behalf as a RATS Relying Party (RRP). As such the RP may be the RATS AR Owner. Alternatively, the AR may directly process Attestation Results.¶
4. OpenID Provider (OP) - an Authorization Server (AS) that implements OIDC such that receipt of an OpenID 'code' from the UA results in the issuance of an OpenID token, 'id-token'. The OP may implement the RATS Relying Party (RRP) role such that issuance of the OpenID token is conditional on suitable Attestation Results. The RP may take on the role of AR Owner to ensure the OP evaluates attestation results that align with its risk requirements.¶
5. Verifier (RV) - a RATS attestation Verifier that processes device Evidence. If the Verifier is combined with the OP, the Verifier becomes an additional processing stage within the OP.¶

3.2. Setup Phase

The setup phase creates the various identity (‘id-token’) and access (‘access-token’) credentials that are used during the operational phase to authorize the exchange of the various OIDC protocol messages.¶

3.3. Operational Phase

The operational phase protocol builds on the abstract OIDC protocol in [OCC2014]. The five OIDC steps are described here for convenience and attestation related steps are described as sub-steps.¶

AuthN_Req = {
    "location": https://op.example.com/authn"
    "client_id": "s6BhdRkqt3",
    "scope": "device-attest"
}

AuthN_Rsp = {
    "client_id": "s6BhdRkqt3",
    "scope": "device-attest",
    "resp_type": "code",
    "authn_proof": "<tbd>"
}

access_token = {
    "iss": "https://jwt-op.example.com",
    "sub": "https://jwt-ra.example.com/24400320",
    "aud": "https://jwt-rp.example.com/s6BhdRkqt3",
    "nbf": 1300815780,
    "exp": 1300819380,
    "claims.example.com/attest-api": true
}

id_token = {
    "iss": "https://jwt-op.example.com",
    "sub": "https://jwt-ra.example.com/24400320",
    "aud": "https://jwt-rp.example.com/s6BhdRkqt3",
    "nbf": 1300815780,
    "exp": 1300819380,
    "name": "Alice"
}

evidence_cmw = [
    "application/eat+jwt",
    "<base64-string containing a JWT>"
]

access_token = {
    "iss": "https://jwt-op.example.com",
    "sub": "https://jwt-rv.example.com",
    "aud": "https://jwt-rp.example.com/s6BhdRkqt3",
    "nbf": 1300815780,
    "exp": 1300819380,
    "claims.example.com/appraisal-api": true
}

evidence_cmw = [
    "application/eat+jwt",
    "<base64-string containing a JWT>"
]

attestation_result_cmw = [
    "application/eat+jwt",
    "<base64-string containing a JWT>"
]