User reference as an assertion

[jricher]

§2.4.1 Identifying the User by Reference: Editor's note:

We might be able to fold this function into an unstructured user assertion reference issued by the AS to the RC. We could put it in as an assertion type of "gnap_reference" or something like that. Downside: it's more verbose and potentially confusing to the client developer to have an assertion-like thing that's internal to the AS and not an assertion.

[fimbault]

Why an assertion? Is that reference supposed to be linked to a session (cf "represent the same end-user to the AS over subsequent requests") or can it be persistent?
I would see that more as an opaque identifier, rather than an assertion.

Something like:

"user": {
   "sub_ids": [ {
     "subject_type": "as_ref",
     "as_ref": "XUT2MFM1XBIKJKSDU8QM"
   } ]
}

as_ref seems a bit specific to GNAP (reference managed by the AS) but it could always be read "as a reference" in a more general setting. There's a variety of generic names that we could choose if needed, local_uid, internal_uid, etc.
But that really asks what additional types we could define as part of secevents (section 7.1.2).

Beyond the case mentioned here, it would be most useful as an opaque identifier when RO != end-user, to avoid leaking private info about the RO (although currently we don't seem to cover that case yet)

It's indeed more verbose than "user": "XUT2MFM1XBIKJKSDU8QM" but at least it's always the same structure (doesn't depend whether it's a reference or not), and it also makes the type more explicit.

[jricher]

A subject identifier makes sense here, and I agree that it should be a new subject_type value to let us constrain it to the GNAP context.

[fimbault]

Fixed by SECEVENT opaque identifiers