[GNAP] Next steps on subject identifiers

[Fabien Imbault <[e-mail]>]

Hi everyone,

Thanks a lot for your participation at IETF110 and on the mailing list. As
agreed during the call, please find a summary and highlight of the next
steps following the discussion item on "subject identifiers" (from an
editorial standpoint this time, after taking into account the feedbacks):

1. fix open issues related to "subject identifiers".

Every item with a question mark (?), in the slides, would love your input.
In particular, some great questions during the meeting:
- what goes into the identifier structure? (question about DIDs was further
discussed in a dedicated thread)
- what goes into the assertion(s) structure?
- how do the identifiers and assertion(s) relate?
- what do we handle in the core spec vs as an extension?

New information: based on SECEVENT draft-07 published this week, we now
have an internal opaque format to use. As per Yaron's suggestion, Justin
has reached out to the SECEVENT WG to enquire about DID support.

The next step is to make PRs (based on sub_ids draft-07), following the now
usual process.
See below for a recap of intended/proposed changes to fix outstanding
issues, the detailed discussions will then be handled through issues and
PRs on github.
-------------------------------------------------------------------------------------------------------------------
Here's the list of suggested intended changes to come next (mostly
normative clean up):
- #16 #42 examples will be based on the sub_ids opaque format #16 #42
- #75 #120 scope of subject identifiers based on sub_id and validation by
the AS (see #49)
- #198 no major change on terminology but a light rewording for "subject
information" (will become "statement asserted by an AS about a subject.")
- #171 "ad-hoc portability" considered out of scope, sub_ids solve a big
part of that
- #51 is fixed by using the SECEVENT opaque format
- #43 #50 assertion will correspond to an id_token authentication event,
and samlv2 gives us a good reason to design the extension registry (a first
step might just be to remove it from the core, due to XML security
considerations / a dedicated issue related to samv2 extension is likely)
- #49 "should/must validate client assertions" ultimately depends on #41,
but "should" seems more realistic. As further guidance, we could move
request.user into request.subject.hints to align with what has been done
for interaction, to clarify the current wording "Subject identifiers are
hints to the AS in determining the RO and MUST NOT be taken as declarative
statements"
- #178 is already with a PR in pending merge, no change to that

Here's the list of issues that won't be addressed just yet (more input from
WG needed):
- #41 assertions as an array: it seems likely we'll need that but as long
as we don't have anything else than id_token, this seems too early to change
- #197 discussion on roles would remain open. Will keep the current wording
for now.
-------------------------------------------------------------------------------------------------------------------

2. get preliminary feedback on the prospective issues, e.g. RO vs end-user.
This is early stage and only for discussion right now. This is
complementary to the "AS as a token factory" presentation by Justin.

Wishing you all a nice day.

The editors