Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-token-authnz-17

[[ nits ]]

[ section 2.1.1 ]
* "(based on local policy)": Also possibly based on "local implementation
  status", or are all clients expected to support all the authentication
  schemes in this particular scenario?

Thank you for addressing my DISCUSS and COMMENT items.

hank you for the work put into this document. The document is clear, easy to read and quite useful even if examples would be welcome.

Please find below just two NITs.

I hope that this helps to improve the document,

Regards,

-éric

== NITS ==

-- section 1.3 --
Expanding "JWT" on first use will be improve readability. And, it is expanded in section 5 ;)

-- section 6 --
Probably better to write "This document has no IANA consideration; just to be clear."

Thanks for this document.  Enabling Open-ID and OAUTH with SIP is quite useful.

This document specifically calls out single sign-on as a reason to use this mechanism, and SSO has a host of serious security and privacy issues.  As those issues are not discussed in the referenced documents, I think they need to be raised here.  Recommended usage/configuration to avoid or mitigate the issues would be ideal, but at the very least I think they need to be documented, as it’s clear that implementors are not aware of them or don’t think they’re important enough to worry about.

Rifaat and I have discussed the above comment and have come up with some text for the Security Considerations that calls out some of the issues, briefly.  Something with more scope than that -- perhaps a BCP about security/privacy concerns with respect to SSO -- is in order, but, clearly, that's way out of scope for this document.

Other, editorial points.

— Section 1.1 —
Please copy the BCP 14 boilerplate exactly from RFC 8174.

— Section 1.3 —

   Refresh Tokens usualy are represented in a reference format

Typo: “usually”.

— Section 3 —

   The methods used and the access
   provided by the token is based on local policy

“are based”, to match the plural subject.

   Examples of such other
   mechanisms are introspection [RFC7662], user profile lookups, etc.

“Examples” and “etc.” are mutually redundant.  I would remove the latter and replace the comma before “user profile lookups” with “and”.

— Section 6 —
This can’t be empty.  It should say that there are no IANA actions needed for this document.

Thank you for addressing my comments!

An additional thing. 

Is SIP directly using the HTTP Authentication Schemes IANA registry (https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#authschemes) or does it have its own tucked away somewhere? And if it is the former, should its references for the "bearer" add this RFC as a reference?