RFC 9493 and sub_id formats
Closed this issue · 11 comments
I suspect in many cases the AS that issues an access_token used to obtain an Txn-Token is going to be different than the Transaction Token Service. In that context, the issuer of the 'subject' of the transaction token is different than the issuer of the transaction token itself.
Section 3.2.3 of RFC 9493 allows for the specification of an issuer and sub within the sub_id object.
Should we require this format? or just leave out of scope of the specification what values are present in the sub_id claim of the transaction token?
I would definitely not require that format.
And would again suggest that RFC 9493 isn't needed in the Txn-Token context and JWT's subject good enough.
My concern with relying on the JWT's subject is that the Transaction Token is issued by the Transaction Token Service which is potentially different than the AS that say issued the access token from which the sub claim is determined. In that context, I think the Transaction Token should carry the issuer of the sub claim which means the default sub and iss claims of the JWT are not sufficient.
Or if the entity requesting the Transaction token is the service that receives inbound mail, and that service wants a transaction token with a purpose of mail.inbox.delivery, is the Transaction Token Service the correct issuer of the sub which is an email address?
I feel like there might be an undue emphasis on a relationship between iss and sub that doesn't truly exist. RFC7519 only mentions uniqueness in the context of an issuer https://www.rfc-editor.org/rfc/rfc7519#section-4.1.2 but not ownership or correctness or semantic meaning.
In the context of OpenID and id_tokens there is a clear relationship between the iss and the sub such that the globally unique identification is the combination of iss and sub. I've always viewed the relationship of those two claims in that light. Maybe that is an OpenID Connect centric view.
Yeah, I am somewhat familiar with OpenID Connect ;) But this isn't OpenID Connect. With a Transaction Token the subject just needs to be identified within a single trust domain.
So that assumes that the sub claim MUST be unique within the single trust domain as identified by the aud claim. This might require the Transaction Token Service (TTS) to do some sort of identifier transformation as well as requiring both the AS and the TTS to both be authoritative for the sub claim value. This is easy if the AS is managing the transaction token request endpoint but if the TTS is it's own service and deployed in a distributed way, would that still be true?
I can see the TTS being authoritative for the single trust domain but not necessarily for the sub identifier. However, I'm ok with moving in the direction you are suggesting Brian; I just want to make sure we aren't prohibiting some deployments by making that simplification.
From discussion...
- 'iss' claim is optional
- be clear that there is no relationship between iss and sub claim
- sub is unique within context of the 'aud' or trust domain
- go back just supporting the
subclaim (no sub_id)
A few months ago, I also suggested to support the sub claim as per JWT RFC. As the current spec has replaced sub_id with sub, I appreciate that the sub claim is supported now.
Since we have removed sub_ids now, I will close this issue.