Original text:
The AS SHOULD NOT re-use subject identifiers for multiple different ROs. <del> Note: the "formats" and "assertions" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </del>  [[ See issue #43 [1] ]]

Reviewer comments:
with array of objects to account for the possibility of several assertions
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 92ab3a878b0995957e39ff9c8cae0726a0fd3f44 Inspect the deploy log: Browse the preview:
As a completely random comment, I find it interesting that computer science commonly refers to an array as a collection of elements with the same data type. It's also a fixed-size collection of elements. URL clearly defines and uses an array. Moreover, it says that what's a bit more important is that this specification should probably use "array of ..." everywhere as this isn't true right now. I see the use of both "list of ..." and "array of ..." at the same time.
Since GNAP is based around JSON for its data model, we use JSON-native data types and their names. The name for an unlabeled, ordered collection is a "JSON array", as you pointed out. If there are places in GNAP where we're using "list" where we should be saying "array", we should fix that.
Todo : inner description to change (key) assertions -> format subid_formats or something like that
Requesting User Information: Editor's note: The values are lifted from ]'s "token type identifiers" list, but is there a better source? : Identifying the User: Editor's note: The keys are lifted from [RFC8693]'s "token type identifiers" list, but is there a better source? Additionally: should this be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway? Returning User Information: Editor's note: Should be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway?
A related topic is , ZKP, etc. A specific type of assertion is used in to prove ownership of a sub (through JWT).
I think that should be an in "Returning User Information". If not, at least, it could be renamed to "assertion" because the current draft uses "assertions" and defines it as . This is a minor editorial thing though. The more major thing is that what are the strong reasons even to mention SAML assertions in the spec? In recent times, XML is often referred to as a potentially insecure format which isn't great due to a long list of vulnerabilities in XML libraries.
We'll discuss that and more at IETF110. I agree that assertions are probably an array (it's not just editorial, and there's another issue open on that) + for the very same reasons you mention I would suggest we remove saml2 assertions from the core (but still we can plan an extension in the registry, already mentioned as a possibility ).
There's now a security consideration related to XML.

Revised text:
The AS SHOULD NOT re-use subject identifiers for multiple different ROs.  <ins> Note: the "sub_id_formats" and "assertion_formats" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </ins> [[ See issue #43 [1] ]]