Draft: draft-ietf-gnap-core-protocol

Commentary: Built To edit notification comments on pull requests , go to your . 
 In 7.3.1 ( use of gnap with HTTP message signatures ) , we do not mention the signature name ( the string for which we always use ) . This is a real issue because multiple signatures are possible on any message . Some options : Specify an explicit name , e.g. or better yet . Include a signature name in the object ( but that would preclude the string version of this parameter ) . 
 I 'm not seeing why this is an issue . Are there security or interoperability concerns ? In the design of HTTP Signatures , the signature 's label ( here ) is meant to be effectively random and not controlled by the application . The label is not covered by the signature , partially for this reason . We actively do n't want people to rely on the value of the signature label at the application level . The reason for this is that the label is only meant as syntax to the carrier and not something that should be relied upon . If any of the attached signatures for a message meet the requirements for the GNAP protocol ( it 's the right key , it covers the right components , it validates correctly ) , then it should be fine no matter what the label is . Furthermore , I would n't expect all libraries to let you set the label explicitly when you 're adding a signature to a message . In other words , you should expect a developer to be able to say " take this message and sign it with this key " and be done with it . The label value would be generated internally , after the value of the body has been created , and that should be fine . 
 Sorry , this still does n't make sense to me . As a receiver , if I get multiple signatures on the same message ( which granted is weird but allowed , and with proxy chains may even be realistic ) , am I really expected to analyze each one of them and apply heuristics to decide which one I like ? And yes , a confused verifier is obviously a security issue . IMO a library that does n't let you set the sig name provides an incomplete interface . 
 Yes , I would expect a receiver to check all signatures and see that : it covers method , target - uri , content - digest , possibly authorization if there 's a token it has a created time that 's not too far in the past it has a tag parameter with the value " gnap " it has a nonce parameter that we have n't seen before in recent - ish memory ( like maybe two or three times the allowable gap from the creation time ) If there 's one that passes all that , then the message is accepted and the other signatures are ignored . This is one of the things that the parameter helps narrow down , because you can immediately filter on that parameter for each signature when you go to process it , more easily ignoring the others . The others might have been by any number of other applications or processes that are n't GNAP . 
 The sole purpose of the signature name is to bind the and header field entries together . They have no semantic value . They could just be randomly generated UUIDs and that would be fine . Support for multiple signatures is n't just an accident of the design ; it 's a very intentional feature . Verifiers must examine each signature on the message until they are satisfied that their requirements are met , and should generally ignore signatures they can not verify . ( e.g. , because they do not understand the key ID , they do not accept the algorithm , the key material is expired , etc . ) I expect that usually a verifier will find either zero or one signatures that satisfy all of its requirements . In some cases , a verifier may permit or even require multiple signatures , for example : service behind a load balancer may expect a signature from the client that covers all of the application - level requirements , and a signature from the load balancer covering the header field . service that sits behind a gateway that transforms requests might expect a signature from the client , and one from the transforming gateway . service could vend out signatures as a way to limit a client 's authorization to make an API request . For example , a vended signature might cover one request parameter , thereby fixing the value that the client can submit for that parameter while allowing the client to control over parameters . Such a service would expect the vended signature along with a client - issued signature covering the vended signature and the remaining request parameters . 
 Also , this is addressed in the security considerations for  , and GNAP relying on the label having a specific value would be counter to that advice : 
 That seems pretty clear , maybe it could help if we 'd extend that considerations with what explained above ? 
 Before going into the more complicated use cases , please add some text that addresses basic interoperability . For example : 
 please let us know if we can merge the PR and close this issue ? 
 Yes , thank you all .
Paragraph (version B):
A received message MAY include multiple signatures, each with its own
label.  The verifier MUST examine all included signatures until it
finds (at least) one that's acceptable according to its policy and
meets the requirements in this section.