Grant Negotiation and Authorization Protocol Resource Server Connections
draft-ietf-gnap-resource-servers-09
Yes
Deb Cooley
No Objection
Gunter Van de Velde
Jim Guichard
(Erik Kline)
(John Scudder)
(Zaheduzzaman Sarker)
Note: This ballot was opened for revision 08 and is now closed.
Deb Cooley
Yes
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Roman Danyliw
No Objection
Comment
(2024-09-30)
Sent
Thank you to Lars Eggert for the GENART review.
** Section 5.3.1
Status Whether or not the format is in active use. Possible values
are Active and Deprecated.
Is there any guidance to the DE on how an existing registry value would have its status changed?
Paul Wouters Former IESG member
Yes
Yes
(2024-10-03)
Sent
Thanks for this clear document and the extensive Security And Privacy Considerations Sections!
Erik Kline Former IESG member
No Objection
No Objection
()
Not sent
Francesca Palombini Former IESG member
No Objection
No Objection
(2024-10-02)
Sent
Thank you for this document. One question about the new IANA registries with Expert Review policy. They do contain a Reference field, which seems to imply that a specification should be publicly available. Experts guidelines are also given to check that the definition for each registered parameter is valid, which I assume would be in such a specification. However nowhere it is stated that the specification should be public (and stable?). You could do like in RFC 7595 and add some text covering the fact that the Expert should check the specification exists and "if no permanent, citable specification (...) is included, credible reasons for not providing it SHOULD be given." This gives more flexibility than Specification required, while covering the requirement on the specification.
John Scudder Former IESG member
No Objection
No Objection
()
Not sent
Murray Kucherawy Former IESG member
No Objection
No Objection
(2024-10-02)
Sent
The document status question in the shepherd writeup was not completed.
Thanks to Rich Salz for his ARTART review.
Possibly an odd question, which you can blame on my DKIM background, but in Section 3.3:
(BEGIN)
The RS signs the request with its own key and sends the value of the access token as the body of the request as a JSON object with the following members:
[...]
proof (string): RECOMMENDED. The proofing method used by the client instance to bind the token to the RS request. The value MUST be in the GNAP Key Proofing Methods registry.
[...]
{
"access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"proof": "httpsig",
"resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
(END)
Is the RECOMMENDED referring to the presence of "proof", or its inclusion in what gets hashed for the signature?
Orie Steele Former IESG member
No Objection
No Objection
(2024-10-01)
Not sent
Thanks to Rich Salz for the ARTART review.
Warren Kumari Former IESG member
No Objection
No Objection
(2024-10-01)
Not sent
Not my area of expertise, so balloting NoObj trusting my co-ADs.
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection
()
Not sent