Treatment of subject in id_token used for code detached signature

[Ralph Bragg]

In the advanced profile, we are proposing to support code id_token for backwards compability. Sub is a mandatory property however if we are trying to ensure that all of the security properties are met and that no useful information can be intercepted in an untrusted network segment like a user agent should we be mandating that SUB is ephemeral, random, pairwise or something else not related to the end customer.

Mandating encrypted id_tokens from the front channel is also a way to address this but may be an overkill given the purpose of id_token is a detached signature?

[Freddi Gyara]

Not sure if this helps, but the sub in the OBIE specification can be set to the consent-id that the authorization deals with.

This effectively makes it ephemeral, but the ASPSP can de-reference it when it wants to find out the actual user associated with it.

[Daniel Fett]

This issue really goes to show how the id_token as a detached signature is a bit of a hack. +1 for recommending an ephemeral/random/pairwise sub for privacy-sensitive applications.

[Dima Postnikov]

+1 for recommending an ephemeral/random/pairwise sub for privacy-sensitive applications.

[Dave Tonge]

Is there still a need for this? It would add complexity to an otherwise simple document.

‌

[Ralph Bragg]

No longer required