Client Backend -> Client Attester

[TakahikoKawasaki]

"Client Backend" in the specification should be replaced with "Client Attester".

"Client Backend" creates the impression that both the client and the system issuing the attestation for the client are managed by the same entity. While it is possible for actual deployments to be structured in this manner, it appears that the specification intends to treat them as separate entities.

[TakahikoKawasaki]

In that sense, the example payload of the Client Attestation JWT in the "Client Attestation JWT" section should be updated from

{
  "iss": "https://client.example.com",
  "sub": "https://client.example.com",
  "nbf":1300815780,
  "exp":1300819380,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "use": "sig",
      "crv": "P-256",
      "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
      "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
    }
  }
}

to

{
  "iss": "https://attester.example.com",
  "sub": "https://client.example.com",
  "nbf":1300815780,
  "exp":1300819380,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "use": "sig",
      "crv": "P-256",
      "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
      "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
    }
  }
}

(Changing the value of the "iss" from "https://client.example.com" to "https://attester.example.com")

[paulbastian]

Hello @TakahikoKawasaki we are having the exact same discussions between the editors, so thanks for your feedback! If you have any further rationale for having separate entities, please let us know

[paulbastian]

I've discussed this issue today with my colleague, we agree to this change.
Especially sub should match the client_id in the issuance.
Version might be separated into an additional, optional attribute

[paulbastian]

add text on iss and sub

[bc-pi]

The iss of the Client Attestation JWT should identify the issuer of the Client Attestation JWT. When it's the client backend (which I think will be a common case), the iss value should be the client id value and the verification key should be found from the jwks_uri or jwks_uri field of that client (however that client info comes to exist with the AS). When the Client Attestation JWT is issued by some attestation service, the iss value should identify that service. And the AS needs to trust the service for this purpose and know how to find verification keys for it.

The sub of the Client Attestation JWT should be the client id value.

[paulbastian]

The iss of the Client Attestation JWT should identify the issuer of the Client Attestation JWT. When it's the client backend (which I think will be a common case), the iss value should be the client id value and the verification key should be found from the jwks_uri or jwks_uri field of that client (however that client info comes to exist with the AS). When the Client Attestation JWT is issued by some attestation service, the iss value should identify that service. And the AS needs to trust the service for this purpose and know how to find verification keys for it.

The sub of the Client Attestation JWT should be the client id value.

This is exactly my opinion.

[bc-pi]

FWIW, I'm not totally convinced there's really a need to allow for an attestation service that's not managed by the same entity as the client but other folks seem to want it so my prior comment assumes it.