`sub` value

[Sakurann]

The text currently says:

The JWT MUST contain a "sub" (subject) claim with a value corresponding to the "client_id" of the OAuth client.

the thing is.. when there could been no pre-existing relationship between the issuer and the wallet. probably worth noting that sub (and client_id value) can be self-attested by the wallet frontend

[tplooker]

I dont think we want to offer too much commentary here about how the client ends up with a client ID that is recognised and trusted by the AS (credential issuer), but I agree the case you raise is permitted.

[tlodderstedt]

Shouldn't we at least describe what identifier is used for further processing (whether to lookup further data or in audit logs)? If the AS trusts the Issuer of the JWT, it should trust it to put a reasonable value in the sub field for further usage.

[tlodderstedt]

I assume in some cases the issuer will out the iss in the sub claim, i.e. whatever data is looked up will be about the issuer (e.g. a wallet provider).

[tplooker]

Apologies im not following you here, I'm inclined to make the iss the client ID as I think the most common case here is that its the client attesting a client instance and make the sub value a client instance ID that is unique per authorization server.

[tlodderstedt]

How have you come to the conclusion that this is the most common case?

My rationale is as follows: if the issuer wants to client id to be the iss value, it puts the iss value in the sub. If the issuer wants the client id to be something else, it uses a different value. I don’t see a need for a client instance identification (at all or as default).

[tplooker]

How have you come to the conclusion that this is the most common case?

I think the most common party signing the client attestation will be the client itself (e.g the backend component), as the AS will need to be able to relate the attestation keys back to the client in order to trust it any way. Do you have usecases where the attester is not the client, I believe this model is complex and we should seriously consider whether we support it. If the attester isn't the client then what do you set the iss value to, what does it mean and how should it influence validation of the attestation?

[tlodderstedt]

In general, I would assume the provider of the client to sign the attestation. However, Bundesdruckerei has implemented as solution where the attestation is issued by a trusted 3rd party.

With respect to the spec: I think it doesn't matter who signs the attestation as long as the AS trusts that party.

[tplooker]

I agree that in effect a trusted 3rd party could do the signing, however I dont believe their identity should be known to the AS (e.g as another protocol participant) instead their identity should still be considered part of the client.

[tlodderstedt]

Why?

[tplooker]

I'm unsure that it provides any value having another identified participant in the protocol seperate from the client. Can you elaborate on the value of why this trusted third party needs be independently identifiable from the client to the AS? How would its identity become know and managed by the AS?

[tlodderstedt]

Again. As long as the AS trusts the issuer of the assertion, it can accept it. I don’t think we need to specify more than that + the sub is the client id. That’s sufficient for interoperability. To the contrary, I don’t see a benefit in limiting the issuer to „the client“.

…

On 18. May 2023 at 12:47 +0200, Tobias Looker ***@***.***>, wrote: I'm unsure that it provides any value having another participant in the protocol seperate from the client. Can you elaborate on the value of why this trusted third party needs be independently identifiable from the client to the AS? How would its identity become know and managed by the AS? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[paulbastian]

I agree the most common use case is the iss being the client backend but we should not limit ourselves here.
I propose iss is the attestation service and sub is a common name for the client aka wallet solution.
In some cases both might be the same but they don't need to be.
Both identifiers might be relevant for a lookup in a trust list

[tplooker]

Understood but I disagree, how does the attestation service become registered with the AS and managed beyond this point e.g in the event of key rotation, we would be adding another entirely new protocol participant for OAuth2 and I'm not sure we've identified any use cases where this would be valuable. Having the attestation service independently identified to the AS would only appear to be valuable when more than one client deployment wants to use the same attestation service, how common is that pattern? Because if we believe its not very common then the most common case where attestation service == client will likely pay a cost of increased complexity. Also what are the implications on the trust model for the AS, when things go wrong in which situations does it blame the client and others when it blames the attestation service?

[tlodderstedt]

How and why the AS trusts the issuer of an attestation is out of scope since it is not relevant on the protocol level. We also haven't defined this in the high assurance profile between verifier and issuer of a VC. I don't understand why we should take a different route here.

Just as an example:
In the EU, the issuer will be maintained in a trusted list all issuers trust.
In a closed deployment, I would assume the trusted attestation issuers are directly maintained at the issuer.

Many ways to get to Rome. We don't need to know all of them, just cater for them.

[tplooker]

How and why the AS trusts the issuer of an attestation is out of scope since it is not relevant on the protocol level

Ok I think perhaps our disconnect is here, how can the notion of "the attestation service" be entirely out of scope of this protocol? Its a party to the protocol who's identity will be crucial in the AS making a trust decision. Do we not need to define at least that the iss value of the client attestation IS an identifier for the attestation service and also how you resolve its keys and manage it in lifecycle? Also as I said before I think giving the AS two things to trust in reference to a client enormously increases the complexity in the trust decision it must make.