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.

[tlodderstedt]

Are all of those details defined in RFC 7523? I don't think so. This a base spec that is further detailed in profiles and deployments. The vc-sd-jwt spec s add also doesn't require a certain key resolution method for the same reason.
It doesn't matter for this spec whether the JWT is issued by a client backend or any other source. Important is that the AS needs to trust this issuer and that this JWT issuer determines the sub value, which is the client id. Anything beyond is subject to other specs in my opinion.
For the high assurance profile, I would assume keys are resolved either web based or with x509, like for the VCs. Other profiles can do it differently.

[tplooker]

Right but RFC 7523 also doesn't formally define a new protocol participant either that the AS must trust independent of the client, instead its implied the keys required to verify the client attestation are associated to the client which is the model I'm proposing we recognise more formally. Are there any deployments of RFC 7523 that exist where the iss value in the assertion is not in some way an identifier for the client?

[tplooker]

Something that was also pointed out to me is that RFC7523 may not require the iss to be the client_id but OpenID's profiling of it did and from what I understand there was no particular reason for RFC7523 to not constrain the iss value in this way, it just didn't. Nor are there really any deployments that have used RFC7523 in a way where the iss value is not the client id.

[peppelinux]

here I share something that emerged during the implementations and comparisons that took place with other analysts

iss and sub should not contain the same value, since the wallet provider (iss) is a separate entity with respect to the wallet instance (sub)

For this reason iss and sub must contain different identifiers, being related to distinct entities.

There are some cases where the client should not have a unique identifier, in this case the sub claim should not be included in the claim, because having iss and sub with identical values ​​would not make sense.

For this reason I propose to make the sub claim OPTIONAL rather than REQUIRED (MUST).

[tlodderstedt]

iss and sub should not contain the same value, since the wallet provider (iss) is a separate entity with respect to the wallet instance (sub)

Why is that and what did emerge during implementations?

[paulbastian]

I think the discussion goes somewhere else now.

Originally the question was whether the attesting entity must be the client backend or can be a trusted third party.

[peppelinux]

Why is that and what did emerge during implementations?

exactly was I wrote in the thread

[tlodderstedt]

I guess you mean "iss and sub should not contain the same value, since the wallet provider (iss) is a separate entity with respect to the wallet instance (sub)"

While I agree on a conceptual level, I don't follow your conclusion that that an attestation needs to have different values for iss and sub. From the issuer's standpoint it is important to know it is talking to an instance of the respective wallet provider/product. It does not need to have an identity/identifier, nevertheless. You seem to agree as you propose to make the sub optional. Why do you think this is the better option than using sub == iss (i.e. self asserted, which to me makes sense).

[peppelinux]

I got your point.

I don't think that iss == sub because the wallet provider attests this to the wallet instance as a personal mobile device.
There might be some cases where the wallet instance is provided as a cloud service, thus this would be a specialized case compatible to your vision.

In the cases where the wallet instance is a personal device, the Wallet Instance Attestation is not self-asserted since Provider and Instance are actually different entities. The issuer attests information in possession and control of the instance, that's a distinct entity under the sole control of the user.

If the attestation is self asserted the private key should be in control of the wallet provider, while this is not the case where personal device are involved.

the wallet provider doesn't have any control on the private keys and general details of the wallet instance, since these are arbitraries

[tplooker]

Related to #12 and #31

[tplooker]

Related discussion also occuring in #13