Original text:
response-interact.  [[ See issue #89 [34] ]] For example, if the request is successful in causing the AS to issue <del> access tokens and release subject claims, the response could look like this: </del>  With this example, the client instance can not make an additional continuation request because a "continue" field is not included.

Reviewer comments:
Replaces most examples by on email, as discussed in and
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 36777fd4186ad5d5f3d9e64c1120277ab52806d2 https://deploy-preview-228--gnap-core-protocol-editors-URL
Requesting User Information: Editor's Note: What we're really saying here is that "even if the AS gives you an email address to identify the user, that isn't a claim that this is a valid email address for that current user, so don't try to email them." In order to get a workable email address, or anything that you can use to contact them, you'd need a full identity protocol and not just this. Also, subject identifiers are asserted by the AS and therefore naturally scoped to the AS. Would changing the name to "assubids" or "localsubids" help convey that point?
Perhaps the example in this section should not include asking for the email here if we want to encourage asking for the email claim from OpenID instead.
NAME that's actually the core point of this issue: there's a semantic difference between asking for "tell me who the current user is, and I know them by an email address identifier" vs. "tell me the email address of the current user so that I can email them". The subject identifiers are the former, OpenID and other identity protocols would give you the latter.
See also .
It would be better to use examples that are not related to emails, to avoid confusion. I believe an "as_uid" (unique identifier local to the AS) could be best as an example that conveys the message.
Yaron: "Subject identifiers requested by the RC serve only to identify the RO in the context of the AS and can't be used as communication channels by the RC" - this sounds a bit naive, people will do that anyway. So why is this a useful statement? (And similarly in 3.4) Justin: This inclusion is based roughly off of a similar constraint in OIDC around subject identifiers: URL I agree that people will do dumb things anyway, but that’s why we need to spell out why it’s dumb here. Yaron: I haven't looked at the OpenID text, but at least here, we do not_ explain why using the email address to send email is a bad idea, we just say that it is. I think we should give a rationale.
There are many reasons why we don't want emails ("should not use email"). No assurance it's unique (ex: EMAIL) No idea on email policy (could be transfered to someone else) Ties to a delivery method (which shouldn't be our goal here) Also not using email facilitates the distinction with what OIDC/authentication mechanisms provide (more an internal argument for the specification text itself). Might also want to push forward privacy enhancing mechanisms.

Revised text:
response-interact.  [[ See issue #89 [34] ]] For example, if the request is successful in causing the AS to issue  <ins> access tokens and release opaque subject claims, the response could look like this: </ins> With this example, the client instance can not make an additional continuation request because a "continue" field is not included.