Change:
[[ See issue #42 [4] ]] <del> Note: the "subject_types" and "assertions" request fields are independent of each other, and a returned assertion MAY omit a requested subject identifier. </del> <ins> Note: the "formats" and "assertions" request fields are independent of each other, and a returned assertion MAY omit a requested subject identifier. </ins> [[ See issue #43 [5] ]]

Discussion:
align with I think however this might be a problem when we already use in the text, in many places (token format, key format, assertion format etc.). Ex in section 2.2, we would have formats (relates to subject identifiers) and just below we discuss assertions: "assertions (array of strings) An array of requested assertion formats." Of course we could change when there's potential confusion, but it shows it's not that straightforward. Therefore I submitted this PR to see what it does, but I think we should hold that change and ask why format is the best term for the job. Types seems more adequate a priori (a type of identifier), but there's probably a reason why they chose format instead. Even if it's still a draft, we should also ask whether it's considered stable, since our syntax depends on it. Of course, if it changes later, a mapping is possible, but that's extra gruntwork for all parties (one of the value of using sub_ids is to make the mapping straighforward). Please let me know what you think. If agreed, I can reach out to the editors.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 328e5750fea6b5e8664b305133695702f6753c86 https://deploy-preview-220--gnap-core-protocol-editors-URL
This PR is also related to as we must consider when more information about a particular subject identifier format needs to be communicated.
To be seen with SECEVENT WG for sub_ids I'm also including some questions from the ML (here Tobias).
Thanks NAME to generalize this beyond DIDs and relate it to your PR , there may be a need to communicate more detail about the subject identifier formats that the client instance supports in its request to the AS.
In my opinion (as an individual), we need to walk a very careful line about the complexity we define around end user information like this. Presenting and receiving both identifiers and assertions is, to me, pretty straightforward. Both are self-contained bits of information that are meant to be taken in a presentation context. Moving beyond this, things could get hairy fast.

I personally think it makes a lot of sense to enable this kind of thing, but I'm inclined to think that this kind of more advanced presentation and negotiation would be better as a DID-specific extension, and I'd like to see what that looks like. One of the things that the core protocol needs to be able to do is support more complex extensions without breaking.
Yes, the first step anyways is to see where SECEVENT lands on with regards to DIDs (just as basic identifiers).
Some text proposal is required to go forward on this issue.
A DID is a reference to a (typically) public control structure called a DID Document. Because DID Documents are presumed public and therefore easily aggregated and indexed, it's desirable to limit their content to only those structures strictly dependent on control by the DID subject. This includes authentication and encryption keys as well as service endpoints. The service endpoints are the demarcation between the public DID Document and private resources under control of the DID controller. DID Service Endpoints can be used for most anything but two particular service types stand out: communication (e.g.: an inbox) and authorization (e.g. an authorization server). A communication endpoint expects to handle a resource directly whereas an authorization server endpoint expects to return an access token to a resource. Either the communication or authorization service endpoints can optionally be proxied by a mediator in order to reduce the risk of correlation across multiple service domains. As end-users to the AS, DID subjects can be either the resource owner or a requesting party. Either way, the DID Document can be an effective way to manage authentication, present claims, and sign requests. A resource owner could use a DID to authenticate to the policy management endpoint of an AS and to provide a service endpoint for AS requests, warnings and errors. Capabilities issued to the resource owner by a resource server (RS) could be delegated to the AS as part of the policy management process. A requesting party could use a DID to present claims and sign requests to the AS with the goal of receiving an access token. When an end-user presents an access token as a capability to an RS, a DID may also be required as a matter of RS policy. The DID might be associated with the end user or with a third-party notary that is part of an audit or accountability process.

Because it is typically pubic, the DID service endpoint considerations for an end-user are tied to the costs of processing unsolicited messages and requests. For example, the service endpoint could expect a refundable deposit to cover processing costs.
Interesting as an overview of possibilities. There are quite a few implications for implementers, who will need guidance on how to do that in practice. I'd suggest to also review the difference between public DIDs vs potentially more restricted DIDs (eg. peer, orb, keri).
DIDs like peer, orb, keri avoid the cost and transparency of a public ledger while preserving the self-certifying feature of DIDs. This does not change anything when DIDs are used for authorization and delegation such as the cost of processing unsolicited messages and requests. The public ledgers themselves do not typically "publish" DIDs or DID Documents either but simply provide a root of trust for the authenticity of a self-certifying DID. The use of any DID and associated assertions incurs a privacy risk to the subject and a cost to either the controller or their delegate. The costs can vary widely across . Resolution, the process of going from a DID to a DID Document, is only costly to the relying party such as an authorization server. Verifying an assertion through a zero-knowledge proofs, for example, can be designed to shift the cost to the end user or the relying party.
Yes indeed, my comment was really related to what we mean "typically", especially when there's such a large variety of methods in the wild, some of which might expose the user more than others. It is entirely possible to publish DIDs and their updates, so a bit of guidance as to what we consider good practice might help.
It might be wise to steer clear of the DID method issues. The DID document I linked above could be enhanced with some GNAP-related points if we have some. GNAP can provide guidance on how to use service endpoints based on the without any method-specific language.
I like the idea.
Closing this issue, as a consequence of secevent update to include DIDs