Should we store each subject item (sub_id sub_id_format) in a separate row? (ie to not store a list as a column)

Should we store each subject item (sub_id sub_id_format) in a separate row? (ie to not store a list as a column)

I'm cool with that - I originally envisioned this as being parallel to how an access row has a column for all the accesses for a given grant, but with subject ids I can see separate rows making sense as they're not as interchangeable as access actions.

@mkurapov So in responding to @cozminu's questions about the subject field in the Grant Continuation response, I notice that subject is not a field that is supported in the token introspection response (see https://datatracker.ietf.org/doc/html/rfc9767#section-5.5.2).

As I understand it, the subject field's value is during the interaction, where the IDP acquires the requested subject information in the /grant/{id}/{nonce}response and verifies that the resource owner performing the interaction owns the wallet address in the requested subject information field. So it's not necessary for subject to be returned in the introspection response.

If we insist on returning the requested subject in the token introspection response, it would have to be part of an opinionated stance on GNAP. Thoughts on keeping subject in the token introspection response? Personally I think we don't need to - the veracity of the subject field should be communicated to the client at the time of interaction completion.

Agreed @njlie. If the RS does not need the subject field (especially since it is not included in the GNAP token introspection response), we shouldn't include it in the response.

ok, so from my understanding the item: `Add logic in token introspection route handler to return the subjects access control for the associated grant in the response.` is not relevant

@cozminu that's correct