Subject: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 2 Dec 2019 07:44:32 -0600

Hi all,

Today starts the Working Group Last Call of 
draft-ietf-sipcore-sip-token-authnz-06.

https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/

The document has changed quite a bit since its predecessor went through 
WGLC.

Please review.  If you submitted feedback on a previous version, make 
sure that it was addressed and your questions answered.

Also appreciated would be any information on implementation plans.

WGLC ends Monday, Dec 16.

Thanks!

Jean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 3 Dec 2019 13:18:27 -0500

I've just reviewed the document again, in full.

There are still a number of areas that need work:

* Section 2.1.1 says:

    The method used to authenticate the user and obtain these tokens is
    out of scope for this document, with one potential method is the
    Native App mechanism defined in [RFC8252].  The advantages of using
    the mechanism defined in [RFC8252] is that the user will be directed
    to use a browser to interact with the authorization server.  This
    allows the authorization server to prompt the user for multi-factor
    authentication, redirect the user to third-party identity providers,
    and the use of single-sign-on sessions.

My problem with this is: the challenge gives the UAC an HTTPS URL of an 
AS. It does not normatively state how the UAC is to use this, or what 
usage(s) the AS MUST support. Hence there is no assurance that the UAC 
will be able to successfully access the AS.

This could be resolved by requiring that the UAC and AS MUST support 
RFC8252. Or perhaps there is some more expansive RFC that can be 
referenced. In the end there needs to be something MTI.

* Section 2.1.2:

You talk about local policy here, but which server's local policy are 
you talking about?

I'm guessing that the AS provides a token containing whatever methods 
have been granted for the user, and the registrar can then use policy to 
decide what method(s) it wants to require for registration. Am I correct 
in assuming that the UAC doesn't play any role in this other than to 
relay the token from the AS to the registrar? And in this case why is 
this point being made in the section about *UAC* behavior?

Can you please clarify the text here?

* Section 2.1.4:

This section says that the UAC MUST include an Authorization header 
field with the Bearer scheme. This is overly strong.

This should be an explanation that *if* it has received a challenge 
containing the Bearer scheme then to resolve that particular challenge 
it needs to send a request with an Authorization header field containing 
the response to that challenge, including the Bearer scheme.

(But note that if there were multiple challenges with different schemes 
then it maybe able to successfully retry the request using non-Bearer 
credentials.)

I don't understand what distinction you are trying to draw by 
distinguishing the behavior for creating a binding from that for 
refreshing a binding. AFAIK there should be no difference. And in fact 
the UAC in general cannot know whether the request being send will 
establish or refresh a binding.

* Section 2.1.5:

This section has similar issues to section 2.1.4: The MUST is too 
strong, and the reason for distinguishing between in-dialog requests 
from others is unclear.

* Section 2.2:

Again is overly strong in its use of MUST. I think it is evident that 
the point being made is that a challenge containing Bearer scheme is the 
way to indicate that is with a challenge with Bearer scheme, but the 
text is at least awkward.

How about:

    When a UAS or Registrar receives a request that fails to contain
    authorization credentials acceptable to it, it SHOULD challenge the
    request by sending a 401 (Unauthorized) response. To indicate that
    it is willing to accept an OAuth2 token as a credential the
    UAS/Registrar MUST include a Proxy-Authentication header field in the
    response, indicate "Bearer" scheme and include an address of an
    Authorization Server from which the originator can obtain an access
    token.

In the second paragraph, please provide a reference:

    ... using the procedures from [RFC???] associated with the type of
    access token used.

* Section 2.3:

Similar comment to section 2.2. How about the following for the first 
paragraph:

    When a proxy receives a request that fails to contain
    authorization credentials acceptable to it, it SHOULD challenge the
    request by sending a 407 (Proxy Authentication Required) response.
    To indicate that it is willing to accept an OAuth2 token as a
    credential the proxy MUST include a Proxy-Authentication
    header field in the response, indicating "Bearer" scheme and
    including an address to an Authorization Server from which the
    originator can obtain an access token.

I don't think the second paragraph should condition any behavior on 
whether it has previously challenged. That requires that the proxy be 
stateful, and it isn't a necessary condition. Instead, how about:

    When a proxy wishes to authenticate a received request, it MUST
    search the request for Proxy-Authorization header fields with 'realm'
    parameters that match its realm. It then MUST successfully validate
    the credentials from at least one Proxy-Authorization header field
    for its realm. When the scheme is Bearer the proxy MUST validate the
    access token, using the procedures from [RFC???] associated with the
    type of access token used.

* Section 3:

The following:

    The realm and auth-param parameters are defined in [RFC3261].

is incomplete, because it is missing 'challenge', 'realm', and 
'https-URI. (Where is https-URI defined?) Another way to do this is by 
adding the following to the syntax:

        challenge = <defined in RFC3261>
        realm = <defined in RFC3261>
        auth-param = <defined in RFC3261>
        scope = <defined in RFC6749>
        error = <defined in RFC6749>
        https-URI = <where???>

(This helps those who might try to formally validate the syntax because 
it removes undefined parameters.)

Also, 'scope' and 'error' are very generic rule names being used in a 
very restricted context. While these are not defined in RFC3261, there 
is the potential conflict with other extensions. I'd recommend using 
more specific terms. E.g.,

        challenge  =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
        bearer-cln = realm / bearer-scope / authz-server / bearer-error /
                     auth-param
        authz-server = "authz_server" EQUAL authz-server-value
        authz-server-value = https-URI
        challenge = <defined in RFC3261>
        realm = <defined in RFC3261>
        auth-param = <defined in RFC3261>
        bearer-scope = <defined as scope in RFC6749>
        bearer-error = <defined as error in RFC6749>
        https-URI = <where???>

Regarding the scope parameter:

This parameter is conveyed from the registrar to the UAC. But what is 
the UAC to do with it? How does it have any control over the scope of 
the token it gets from the AS? Is the UAC supposed to convey this to the 
AS? If so, how?

Regarding the error parameter:

Is this just intended to be of help in debugging the UAC? Or is it 
expected that the UAC might take some sort of pre-programmed action in 
response? If the latter, how might that work? Is this information 
suitable for presentation to the user?

* Section 4:

I agree with Dale - I don't see any value in this tag. I tried to search 
for all discussion on the point. The discussion attributes me with 
requesting it, but I don't think I did.

* Missing:

I find no syntax extensions for Authorization and Proxy-Authorization. 
These need to be added.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Dec 2019 08:00:09 +0000

Hi Paul,

My comments on some of your SIP-related issues (I am not addressing your issues on Sections 2.1.1 and 2.1.2 in this reply). 

>    the response to that challenge, including the Bearer scheme.
  
I suggest that we expand the first paragraph in the section. Something like:

"The procedures in this section apply when the UAC has received a challenge that contains a Bearer scheme, 
and the UAC has obtained a token as specified in section Section 2.1.1."
  
>    establish or refresh a binding.
  
It is important to point out that the same access token might not necessarily be used throughout the lifetime of the registration, if the previously included access token has expired.

---
 
>    strong, and the reason for distinguishing between in-dialog requests 
  
See my comments for 2.1.4.

---

>        Authorization Server from which the originator can obtain an access
  
WFM.
  
>        ... using the procedures from [RFC???] associated with the type of
  
Ok.

---
  
>        originator can obtain an access token.
  
WFM.

>        type of access token used.
  
WFM.

---

>    'https-URI. (Where is https-URI defined?) 
>
> Another way to do this is by  adding the following to the syntax:
>    

The section does enhance 'challenge', so I guess we can add text saying that 'challenge' is defined in RFC 3261.

Regarding the other parameters, the text already says where they are defined.

Or, are you saying that you want the references in the syntax, rather than in the normative text?

>            bearer-error = <defined as error in RFC6749>

The HTTP WWW-Authenticate header field uses 'error' and 'scope', and I think it would be good to be aligned.
  
>    the token it gets from the AS? Is the UAC supposed to convey this to the 
  
The UAC will get the scope from the AS, and will forward it towards the UAS/registrar.
  
>    suitable for presentation to the user?
  
I see no reason why it can't be presented to the user, and I guess the UAC actions depend on what the error code is.

However, as the parameter is described in RFC 6749, I don't think we need to repeat that in this draft.

---
  
>    requesting it, but I don't think I did.
  
It was Olle who requested it.

However, I don't see any harm in having it. It allows the UAC to inform proxies/UAS/Registrar whether it supports the bearer scheme.

---

>    I find no syntax extensions for Authorization and Proxy-Authorization. 
  
Ok.

Regards,

Christer

---

From: Jörgen Axell <[email-masked]>
Date: Wed, 4 Dec 2019 13:53:32 +0000

A few nits:
1.2: Second bullet: maintainings-->maintaining
2.1.1: shouldn't "out of scope for" be "out of scope of"?
2.1.3: this specifications--> this specification
2.1.4: Authorization headerf-->Authorization header
2.2: end of first para, from there-->from where
2.3: same as 2.2
3: In BNF we have authz-server parameters. Shouldn't this be authz-server-value?
5.1: The figure belows show--> The figure below shows
below the figure: autentication-->authentication
5.2: The figure belows as above.

Regards,
Jörgen
-----Original Message-----
From: sipcore <[email-masked]> On Behalf Of A. Jean Mahoney
Sent: den 2 december 2019 14:45
To: SIPCORE <[email-masked]>; [email-masked]
Subject: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz

Hi all,

Today starts the Working Group Last Call of draft-ietf-sipcore-sip-token-authnz-06.

The document has changed quite a bit since its predecessor went through WGLC.

Please review.  If you submitted feedback on a previous version, make sure that it was addressed and your questions answered.

Thanks!

Jean

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 7 Dec 2019 10:37:46 +0000

Hi Jörgen,

Thanks for your feedback! We will do the fixes as suggested.

Regards,

Christer

________________________________
From: sipcore <[email-masked]> on behalf of Jörgen Axell <jorgen.axell=[email-masked]>
Sent: Wednesday, December 4, 2019 3:53 PM
To: A. Jean Mahoney <[email-masked]>; SIPCORE <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz

A few nits:

Regards,
Jörgen
-----Original Message-----
From: sipcore <[email-masked]> On Behalf Of A. Jean Mahoney
Sent: den 2 december 2019 14:45
To: SIPCORE <[email-masked]>; [email-masked]
Subject: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz

Hi all,

Thanks!

Jean

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 8 Dec 2019 07:29:30 -0500

Hi Paul,

Thanks for the detailed review.

Regarding the

I think that MUST is too strong in this case. I would be fine with a
SHOULD, as there are different ways to achieve this based on the type of
UAC, e.g. a browser-based UAC application.
Thoughts?

Regarding your comment about section 2.1.2, I agree with you; I will move
it to its own section.

Regards,
 Rifaat

On Wed, Dec 4, 2019 at 3:00 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> Hi Paul,
>
> My comments on some of your SIP-related issues (I am not addressing your
> issues on Sections 2.1.1 and 2.1.2 in this reply).
>
> >    * Section 2.1.4:
> >
> It is important to point out that the same access token might not
> necessarily be used throughout the lifetime of the registration, if the
> previously included access token has expired.
>
> ---
>
> >    * Section 2.1.5:
> >
> I see no reason why it can't be presented to the user, and I guess the UAC
> actions depend on what the error code is.
>
> However, I don't see any harm in having it. It allows the UAC to inform
> proxies/UAS/Registrar whether it supports the bearer scheme.
>
> ---
>
> >    * Missing:
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 8 Dec 2019 17:17:51 -0500

Hi Rifaat,

> UAC, e.g. a browser-based UAC application.

I agree there can be variation based on type of UAC. E.g., actually 
using a browser and having the end user interact with it, vs. a UAC that 
is an automaton and doesn't have a user.

But in the end whatever it is must use the URI as the starting point for 
the interaction. With a browser interface presumably the URI is used to 
fetch a page that is presented to the user. And the user then can 
determine in a human intuitive way how to interact with that page to 
complete the authentication. If it is an automaton then that won't work. 
It must have *some* way of determining how to interact with the web 
server and present what facts it has (e.g. user id and pw) to that 
server in order to complete authentication. And in either case, there 
must be a well defined way of learning if it succeeded and conveying the 
resulting token back to the sip server.

RFC8252 seems to try to specify this at least in some cases, though it 
is still fuzzy to me. This should be deterministic - it shouldn't be 
neccessary for an automaton to be specially programmed for how to 
interact with the particular AS and how to convey the result back to the 
sip server.

> Regarding your comment about section 2.1.2, I agree with you; I will 
> move it to its own section.

Moving it to a separate section isn't necessary or sufficient. It needs 
to be clarified.

I'm assuming responses to my other points will be coming later.

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
> 
> 
> On Wed, Dec 4, 2019 at 3:00 AM Christer Holmberg 
> <christer.holmberg=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Paul,
> 
>     My comments on some of your SIP-related issues (I am not addressing
>     your issues on Sections 2.1.1 and 2.1.2 in this reply).
> 
>      >    * Section 2.1.4:
>      >
>     necessarily be used throughout the lifetime of the registration, if
>     the previously included access token has expired.
> 
>     ---
> 
>      >    * Section 2.1.5:
>      >
>     The section does enhance 'challenge', so I guess we can add text
>     saying that 'challenge' is defined in RFC 3261.
> 
>     I see no reason why it can't be presented to the user, and I guess
>     the UAC actions depend on what the error code is.
> 
>     However, I don't see any harm in having it. It allows the UAC to
>     inform proxies/UAS/Registrar whether it supports the bearer scheme.
> 
>     ---
> 
>      >    * Missing:
>      >
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Dec 2019 08:37:43 +0000

Hi Paul,

I replied to your other points last week.

Regards,

Christer

On 09/12/2019, 0.18, "Paul Kyzivat" <[email-masked]> wrote:

    Hi Rifaat,

    

    

    	Thanks,
    	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 13 Dec 2019 09:02:20 -0500

> interact with the particular AS and how to convey the result back to the
There are different ways that a UAC can act on the HTTPS URI, depending on
the type of UAC.
Here are few examples:
1. RFC8252 for Native Apps
2. RFC8628 for browser-less devices
3. https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ for
browser-based apps

New mechanisms could be defined and added to address other use case not
covered by existing mechanisms.

This is the reason I am really hesitant to add any normative text and
require any specific mechanism.
I still think this is out of scope for this document, and any text should
be informative only.

> Ok. I will clarify it.

> I'm assuming responses to my other points will be coming later.
Christer provided feedback on the rest of you comments. Do you have any
further comment on Christer's responses?

Regards,
 Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Dec 2019 14:57:35 +0000

Hi,

>> complete the authentication. If it is an automaton then that won't work.. 
> There are different ways that a UAC can act on the HTTPS URI, depending on the type of UAC. 
> Here are few examples:
> 3. https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ for browser-based apps
>
> New mechanisms could be defined and added to address other use case not covered by existing mechanisms.
>
> This is the reason I am really hesitant to add any normative text and require any specific mechanism. 
> I still think this is out of scope for this document, and any text should be informative only.

I agree. 

Regards,

Christer

> <mailto:mailto:[email-masked]>> wrote:
> 
>     Hi Paul,
> 
>      >    * Section 2.1.4:
>      >
>      >    This section says that the UAC MUST include an Authorization
>     header
>      >    field with the Bearer scheme. This is overly strong.
>      >
>      >    This should be an explanation that *if* it has received a
>     challenge
>      >    containing the Bearer scheme then to resolve that particular
>     challenge
>      >    it needs to send a request with an Authorization header field
>     containing
>      >    the response to that challenge, including the Bearer scheme.
> 
>      >    (But note that if there were multiple challenges with
>     different schemes
>      >    then it maybe able to successfully retry the request using
>     non-Bearer
>      >    credentials.)
>      >
>      >    I don't understand what distinction you are trying to draw by
>      >    distinguishing the behavior for creating a binding from that for
>      >    refreshing a binding. AFAIK there should be no difference. And
>     in fact
>      >    the UAC in general cannot know whether the request being send
>     will
>      >    establish or refresh a binding.
> 
>      >    * Section 2.1.5:
>      >
>      >    This section has similar issues to section 2.1.4: The MUST is too
>      >    strong, and the reason for distinguishing between in-dialog
>     requests
>      >    from others is unclear.
> 
>      >    * Section 2.2:
>      >
>      >    Again is overly strong in its use of MUST. I think it is
>     evident that
>      >    the point being made is that a challenge containing Bearer
>     scheme is the
>      >    way to indicate that is with a challenge with Bearer scheme,
>     but the
>      >    text is at least awkward.
>      >
>      >    How about:
>      >
>      >        When a UAS or Registrar receives a request that fails to
>     contain
>      >        authorization credentials acceptable to it, it SHOULD
>     challenge the
>      >        request by sending a 401 (Unauthorized) response. To
>     indicate that
>      >        it is willing to accept an OAuth2 token as a credential the
>      >        UAS/Registrar MUST include a Proxy-Authentication header
>     field in the
>      >        response, indicate "Bearer" scheme and include an address
>     of an
>      >        Authorization Server from which the originator can obtain
>     an access
>      >        token.
> 
>     WFM.
> 
>      >    In the second paragraph, please provide a reference:
>      >
>      >        ... using the procedures from [RFC???] associated with the
>     type of
>      >        access token used.
> 
>     Ok.
> 
>     ---
> 
>      >    * Section 2.3:
>      >
>      >    Similar comment to section 2.2. How about the following for
>     the first
>      >    paragraph:
>      >
>      >        When a proxy receives a request that fails to contain
>      >        authorization credentials acceptable to it, it SHOULD
>     challenge the
>      >        request by sending a 407 (Proxy Authentication Required)
>     response.
>      >        To indicate that it is willing to accept an OAuth2 token as a
>      >        credential the proxy MUST include a Proxy-Authentication
>      >        header field in the response, indicating "Bearer" scheme and
>      >        including an address to an Authorization Server from which the
>      >        originator can obtain an access token.
> 
>     WFM.
> 
>      >    I don't think the second paragraph should condition any
>     behavior on
>      >    whether it has previously challenged. That requires that the
>     proxy be
>      >    stateful, and it isn't a necessary condition. Instead, how about:
>      >
>      >        When a proxy wishes to authenticate a received request, it
>     MUST
>      >        search the request for Proxy-Authorization header fields
>     with 'realm'
>      >        parameters that match its realm. It then MUST successfully
>     validate
>      >        the credentials from at least one Proxy-Authorization
>     header field
>      >        for its realm. When the scheme is Bearer the proxy MUST
>     validate the
>      >        access token, using the procedures from [RFC???]
>     associated with the
>      >        type of access token used.
> 
>     WFM.
> 
>     ---
> 
>      >    * Section 3:
>      >
>      >    The following:
>      >
>      >        The realm and auth-param parameters are defined in [RFC3261].
>      >
>      >    is incomplete, because it is missing 'challenge', 'realm', and
>      >    'https-URI. (Where is https-URI defined?)
>      >
>      > Another way to do this is by  adding the following to the syntax:
>      >
>      >            challenge = <defined in RFC3261>
>      >            realm = <defined in RFC3261>
>      >            auth-param = <defined in RFC3261>
>      >            scope = <defined in RFC6749>
>      >            error = <defined in RFC6749>
>      >            https-URI = <where???>
>      >
>      >    (This helps those who might try to formally validate the
>     syntax because
>      >    it removes undefined parameters.)
> 
>      >    Also, 'scope' and 'error' are very generic rule names being
>     used in a
>      >    very restricted context. While these are not defined in
>     RFC3261, there
>      >    is the potential conflict with other extensions. I'd recommend
>     using
>      >    more specific terms. E.g.,
>      >
>      >            challenge  =/  ("Bearer" LWS bearer-cln *(COMMA
>     bearer-cln))
>      >            bearer-cln = realm / bearer-scope / authz-server /
>     bearer-error /
>      >                         auth-param
>      >            authz-server = "authz_server" EQUAL authz-server-value
>      >            authz-server-value = https-URI
>      >
>      >            challenge = <defined in RFC3261>
>      >            realm = <defined in RFC3261>
>      >            auth-param = <defined in RFC3261>
>      >            bearer-scope = <defined as scope in RFC6749>
>      >            bearer-error = <defined as error in RFC6749>
>      >            https-URI = <where???>
> 
>      >    Regarding the scope parameter:
>      >
>      >    This parameter is conveyed from the registrar to the UAC. But
>     what is
>      >    the UAC to do with it? How does it have any control over the
>     scope of
>      >    the token it gets from the AS? Is the UAC supposed to convey
>     this to the
>      >    AS? If so, how?
> 
>      >    Regarding the error parameter:
>      >
>      >    Is this just intended to be of help in debugging the UAC? Or
>     is it
>      >    expected that the UAC might take some sort of pre-programmed
>     action in
>      >    response? If the latter, how might that work? Is this information
>      >    suitable for presentation to the user?
> 
>      >    * Section 4:
>      >
>      >    I agree with Dale - I don't see any value in this tag. I tried
>     to search
>      >    for all discussion on the point. The discussion attributes me
>     with
>      >    requesting it, but I don't think I did.
> 
>      >    * Missing:
>      >
>      >    I find no syntax extensions for Authorization and
>     Proxy-Authorization.
>      >    These need to be added.
> 
>     Ok.
> 
>     Regards,
> 
>     Christer
> 
> 
> 
>     mailto:[email-masked] <mailto:mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Dec 2019 11:14:22 -0500

Rifaat,

On 12/13/19 9:02 AM, Rifaat Shekh-Yusef wrote:

> 3. 
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ for browser-based 
> apps
> 

I know very little about web development, and so I found 
draft-ietf-oauth-browser-based-apps very difficult to understand. But 
based on that I think I realize a bit of where it is coming from:

With a browser based web app, the code running in the browser may be 
provided by the web app it is talking to. In that case they can have 
customized implicit knowledge of the inner workings of each other and 
the mechanics of the interaction between the two need not be standardized.

The question is, what does that have to do with sip? Are you imagining a 
case where there is a browser based sip client that has been served to 
the browser by a web server that has implicit knowledge of the workings 
of the sip registrar?

My concern is driven by an expectation that sip client MAY be an 
independent entity has no knowledge of the workings of the sip server. 
In that case the *only* knowledge it has in support of authentication is 
what comes in the authorization challenge. That MUST be sufficient 
information, together with information it can get by asking the end user 
in realtime, to complete the authentication and successfully retry the 
request with proper credentials. IIUC the current spec doesn't 
accomplish that.

I get the impression (though I am far from sure) that you are trying to 
cover cases where the sip server assumes that the client has been custom 
implemented to work with that server. If so, I don't think that is an 
appropriate stance for a sip standard.

> further comment on Christer's responses?

I don't recall. I'll have to check back.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Dec 2019 12:37:43 -0500

On 12/13/19 9:02 AM, Rifaat Shekh-Yusef wrote:
> 
> 
> On Sun, Dec 8, 2019 at 5:17 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:

> further comment on Christer's responses?

Hmm. I can find no evidence that I received Christer's reply. But I have 
now found it in the archives. I will reply based on the text from the 
archive. I'm sorry that this isn't properly threaded into the replies.

> and the UAC has obtained a token as specified in section Section 2.1.1."

OK

> It is important to point out that the same access token might not necessarily be used throughout the lifetime of the registration, if the previously included access token has expired.

Fine. It is good to cover that. But it shouldn't be conflated with 
creating vs. refreshing a binding. For instance, the UAC may have 
knowingly allowed a registration to expire and yet still cached the 
credentials (tokens). Then later it might want to reestablish a 
registration using cached credentials. At that time it can decide if its 
access token is still good, and if not use its refresh token to get a 
fresh one, and then either way use that preemptively in its register 
request.

> Or, are you saying that you want the references in the syntax, rather than in the normative text?

I'm just *suggesting* that doing so in ABNF will make life easier for 
anybody who wants to process the abnf using tools.

> The HTTP WWW-Authenticate header field uses 'error' and 'scope', and I think it would be good to be aligned.

The context in which abnf from HTTP is processed is distinct from that 
in which SIP abnf is processed.

Consider somebody who is trying to pull together complete abnf for sip 
and all the sip extensions that they implement. All the rule names newly 
defined in one sip extension need to be distinct from those defined in 
other sip extensions. (Except in cases of extensions to extensions.)

If the new rule names are sufficiently unique to effectively eliminate 
conflicts then all should be good. If common words are used as rule 
names, then multiple extensions may inadvertently conflict. We have no 
mechanisms for easily detecting such conflicts.

I'm just trying to suggest practices that help with this. I don't think 
that what I suggest above will confuse anyone that is familiar with the 
HTTP abnf.

> The UAC will get the scope from the AS, and will forward it towards the UAS/registrar.

I'm confused. According to RFC6749 the client and user agent are passing 
the scope *to* the AS. Then (I think) that influences whether a token is 
returned and if so which one. In our context here, I gather that the 
registrar is conveying the scope for credentials it will accept. Then I 
guess the UAC is expected to pass this on to the AS.

I think the processing of scope needs more explanation.

> However, as the parameter is described in RFC 6749, I don't think we need to repeat that in this draft.

I'm not sure I understand it there, but it appears to me that the error 
parameter is returned by the AS to the client in response to a request 
for a token. In that case I don't see why it will be present in a 
WWW-Authenticate header field.

Can you explain the flow that results in this being in WWW-Authenticate?

> However, I don't see any harm in having it. It allows the UAC to inform proxies/UAS/Registrar whether it supports the bearer scheme.

There is no particular harm other than added complexity and the 
likelihood that others will in the future ask about it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Dec 2019 18:49:31 +0000

Hi Paul,

...

>    the browser by a web server that has implicit knowledge of the workings 

I am not sure what "workings of the sip registrar" you are referring to.

The user/application obviously need to support at least one of the OAuth application server providers used by the registrar. If it doesn't, authentication will fail. That is normal behavior for web applications. However, when a user makes a contract with the registrar operator, the user will normally be told which application server providers are supported by the operator.

>    what comes in the authorization challenge. 

It doesn't need to know more.

> That MUST be sufficient  information, together with information it can get by asking the end user 
> in realtime, to complete the authentication and successfully retry the request with proper credentials. 
> As far as SDP is concerned, the only format is 'webrtc-datachannel'.

It gets that information in the 401/407 response. The HTTPS URI indicates which application server provider is used, so the application can query the credentials associated with that application server and perform the OAuth procedures with the application server.

>    appropriate stance for a sip standard.
  
The server only assumes that the client supports OAuth - which the client can indicate using the media feature tag.

Regards,

Christer