Re: [sipcore] Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT

[Roman Danyliw <[e-mail]>]

Hi Rifaat and Christer!

Thanks for the updates made in -14 and -15.  They address both my DISCUSS and COMMENT items.  I’ve cleared my ballot.

Regards,
Roman

From: Rifaat Shekh-Yusef <[e-mail]>
Sent: Wednesday, April 22, 2020 1:58 PM
To: Christer Holmberg <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Jean Mahoney <[e-mail]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT

Hi Roman,

Thanks for the review!

Regarding the DISCUSS:

Section 2.1.1, 3rd paragraph, last sentence, has a bit more about the usage of the ID Token. How about extending that as follows:
An OpenID Connect server returns an additional ID Token that contains claims about
the authentication of the user by an Authorization Server. The ID Token can potentially
include other optional claims about the user, e.g. the SIP URI, that will be consumed by
the UAC and later used to register with the SIP Registrar.

More inline regarding some of the comments.

Regards,
 Rifaat



On Wed, Apr 22, 2020 at 12:28 PM Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
HI Roman,

Thank You for the review! In this reply I will address most of your COMMENT issues. The DISCUSS issue, and a couple of COMMENT issues, will be addressed in a separate reply.

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    >** Section 1.3.  Per “Access Tokens could be represented in one of the above
    >two formats.”, if not one of these two formats, then which other ones?

    I suggest to change "could" to "can".

How about replacing "could be" with "are"?


---

    > ** Section 2.1.1.  Per “An OpenID Connect server …”, based on the flows
    > depicted in Figure 1 and 2, how the OpenID Connect server fits isn’t clear.

We will address this in the reply that addresses the DISCUSS, as the issues are related.
The AS could be a typical OAuth Authorization Server or an OpenID Provider (OP).
Would changing the "AS" column in the figures to "AS/OP" help?


---

    > ** Section 2.1.2.  Per “Endpoints that support this specification MUST support
    > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access
    > tokens when they are included in SIP requests, unless some other mechanism is
    > used to guarantee that only authorized SIP endpoints have access to the access
    > token.” -- is it the “use of” or “support for” JWT that is required if there
    > isn’t an alternative?  Section 5 uses similar language.

"MUST use" is more correct.

---

    > ** Section 2.1.3.  Per “Note that, if there were multiple challenges with
    > different schemes, then the UAC may be able to successfully retry the request
    > using non-Bearer credentials.”, would that decision be made based on local
    > policy?

Yes. That is described in Section 2.1.1.<http://2.1.1.>:

   "If the UAC receives a 401/407 response with multiple WWW-
   Authenticate/Proxy-Authenticate header fields, providing challenges
   using different authentication schemes for the same realm, the UAC
   selects one or more of the provided schemes (based on local policy)
   and provides credentials for those schemes."

---

    > ** Section 5.  Should the use of the scope parameter be noted (or RECOMMENDED)
    > to narrow the utility of the token?

    I will refer this to Rifaat.

How about adding the following sentence to this section:

The SIP Registrar SHOULD include a Scope parameter to control the minimum level of service access
the client is required to obtain from the Authorization Server to be able to register with the SIP Registrar.

Regards,
 Rifaat


---

    > ** Editorial Nits:
    > Section 1.3.  Typo. s/usualy/usually/

    Will fix.

    > Section 7.  Typo.  s/coversion/conversion/

    Will fix.

---

Regards,

Christer