Trust

[Sakurann]

make it clear that the receiver of the attestation needs to trust the signer of the attestation and pre-obtain(?) the keys to validate it?

[bc-pi]

I would imagine the client is configured/registered with the AS and the jwks or jwks_uri of that client is where the verification keys are found. Basically the trust comes from the client configuration record at the AS (however that comes to be) and the keys are obtained from the client jwks/jwks_uri metadata.

[tplooker]

I agree with Brian, I dont think we want this draft to define how the keys required to validate the attestation MUST be obtained because that is really based on how the client comes to be configured at the AS and as a result there could be multiple mechanisms. There may be a need to add some language that makes this clearly however I will note that RFC 7523 doesn't speak to this for the assertions it defines.

[peppelinux]

The key point is the digital trust relationship that allows a client to be registered and attestable as realiable and eligible in relation to one or more trust frameworks, and for any following transactions, outside the client registration, that may happen in a defined period of time, beyond which trust with that client must be re-evaluated.

Given that having a client registered previously or obtaining its public keys though TLS doesn't give any assurance about the compliance of that client in the present, in relation to privacy and security preserving trust model. We shoudl consider that a client, that's a participant in a Auth/eID infrastructure, may lose its compliance and consequently be banned because of this. The requirement to be met is to allow an automatic method for evaluating the revocation status of the client, if the determining authority (TTP) is outside the party (AS and Client)

another key point is that trusted attestations, which allow a customer to be registered and then allow data interchange with it, are considered long-lived attestations, for the satisfaction of non-repudiation requirements for years to come.

[bc-pi]

Just to add a bit of context about the comment about RFC 7523 - it doesn't speak to this stuff in specific terms but does have some discussion in Interoperability Considerations that's pretty open ended. RFC7523 came before "Dynamic Client Registration" in RFC7591. But since then the metadata defined in RFC7591, and registered extensions to it, have come to imply a general data model for clients that is useful and used for authorization server implementations, even when the Dynamic Client Registration Protocol isn't in play. That includes jwks/jwks_uri metadata as the place for key(s). OIDC core kinda follows and pushes that pattern too and even 'profiles' RFC7591 somewhat with its definition of private_key_jwt. So, regardless of how a client comes to be configured, the jwks or jwks_uri client metadata fields really have become the de facto for where/how client keys are obtained. I think this draft could acknowledge and/or provide some guidance in that direction. The AS would have one client config record for the whole client system and the verification keys for the attestation assertion come from the jwks or jwks_uri fields of that record. "Trust" comes from how that client record comes to be configured, but that how is out of scope of this draft.

[peppelinux]

I start from the assumption that OpenID Connect Federation confirms the traditional methods to get the jwks, using jwks/jwks_uri, enabling the jwks claim for the openid connect providers metadata as well.

I want to start from the example below and answering to the question "How can you trust such client?"

{
  "alg": "ES256",
  "kid": "11",
  "trust_chain": [ ... ]
}
.
{
  "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"
    }
  }
}

if we would have a x5c header parameter instead of the Federation Trust Chain, the Key Attestation would be realiable according to a x509 PKI.

Using the Federation Trust Chain we are able to:

• get the public key corresponding to the kid 11
• get the trust relationships between the client and one or more Trusted Third Parties
• get the metadata related to that client (and all its jwks ...)
• get the policy to be applicable to the metadata, following what configured by the Trusted Third Parties for this client
• verify the trust chain over years, even if the public keys needed for verification are changed to one or multiple trusted third party or in the client as well

I'm aware that attesting keys is just attesting keys but the model would require how to attest the owner of that key as reliable? How do you trust that client, since it has self issued that attestation?

I suggest to introduce the topic of Trust Establishment in this Draft, to give some pointers or refs to the ways we have todate to verify the reliability of an attestation, since a self-signed attestation is not attestable as secure.

At the same time there may be the possibility that a client attestation should be issued by a trusted third party, so the question would are:

• Is there a single Trusted Third Party?
• Is there any way the Trusted Third Party has to delegate the issuing of the attestations to another party as an intermediate?
• Is there the need to obtain the public keys of all the Trusted Third Parties, if more than a single? If yes, how to know who these are?

I'm asking since I found these answers in OpenID Connect Federation and the questions above are the classical questions the analysts/implementers have when deals with client attestations or dynamic client registrations

[peppelinux]

Another example to exemplify the differences bwtween key attestation and assurance of reliability.

A crypto key Is a key Just as a Key of a hotel room

Given that that Key effectively works for its hotel room, the question Is: which reputation has that hotel? How many "stars" does It have? Who give those "stars"? Which are the evaluation parameters and for how long will these be valid? Will be a day when the hotel owner may say to have never give that room to a client, or that such client was never seen before? Which trust framework will protect both hotel owner and client from unwanted actions they may do against each other?

assurance of reliability is something verifiable, even If I'm aware that Trust is more a strategy and the Trust Model should define the rules and the architectural components to implement this strategy. A Strategy won't give us the assurance that a bad action won't be made by an Entity but at the same time the model must give also the assurance that every proof must be non repudiable and issued as long-lived, to give the guarantee to the participants that even if a rogue participant will break the rules of the trust, the proofs will be always verifiable in the future (especially when public keys will change)