Draft: draft-ietf-gnap-core-protocol

Commentary: 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 https://deploy - preview-220 - -gnap - core - protocol - editors- 
 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  ) . 
 Thanks 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   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 .  , orb ,  ) . 
 DIDs like peer , orb ,  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
Paragraph (version A):
Note: the "subject_types" and "assertions" request fields are
independent of each other, and a returned assertion MAY omit a
requested subject identifier.
Paragraph (version B):
Note: the "formats" and "assertions" request fields are independent
of each other, and a returned assertion MAY omit a requested subject
identifier.