What's wrong: subject.id is defined as "an opaque string, unique within the issuing AS's namespace. No format constraint is imposed." A claim like "this data belongs to person X" is only ever an assertion by one authorization server — it isn't portable or checkable by anyone who doesn't already trust that specific AS.
What I'd change: Optionally allow subject.id to be, or be accompanied by, a self-certifying identifier the subject controls (e.g. a DID), so a third party could verify a grant is bound to a specific person's key rather than to a row in one AS's database.
Why: As specified, ownership claims don't survive the AS disappearing, rotating identifiers, or a third party wanting to verify without trusting that AS. That undercuts the "who owns/controls this data" question the portability goal implies should be answerable on the data itself, not only by calling back to the issuer.
(Section: 7. Grant — subject.id)
What's wrong:
subject.idis defined as "an opaque string, unique within the issuing AS's namespace. No format constraint is imposed." A claim like "this data belongs to person X" is only ever an assertion by one authorization server — it isn't portable or checkable by anyone who doesn't already trust that specific AS.What I'd change: Optionally allow
subject.idto be, or be accompanied by, a self-certifying identifier the subject controls (e.g. a DID), so a third party could verify a grant is bound to a specific person's key rather than to a row in one AS's database.Why: As specified, ownership claims don't survive the AS disappearing, rotating identifiers, or a third party wanting to verify without trusting that AS. That undercuts the "who owns/controls this data" question the portability goal implies should be answerable on the data itself, not only by calling back to the issuer.
(Section: 7. Grant —
subject.id)