Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-04.txt

[Paul Kyzivat <[e-mail]>]

On 10/22/19 8:45 PM, Rifaat Shekh-Yusef wrote:
> 
> 
> On Mon, Oct 21, 2019 at 11:40 AM Paul Kyzivat <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Rifaat,
> 
>     On 10/19/19 4:23 PM, Rifaat Shekh-Yusef wrote:
>      > All,
>      >
>      > We update the draft based on the latest comments, mainly from Paul.
>      > Please, take a look and let us know what you think.
> 
>     Thanks. This is better. I have some followup questions to broaden my
>     understanding. (Once I understand better, I may have some
>     suggestions on
>     how to make the document clearer in this regard.)
> 
>     IIUC, upon getting a challenge for which there is no cached response,
>     the typical expected behavior for a UA is to launch a browser using the
>     URL from the authz-server-value in the challenge. Is that right?
> 
>     I'm not clear on the sequence of events following that. IOW, I'm
>     looking
>     for more detail on step [3] in the figure in section 5.1. I would
>     expect
>     that this first action of the browser will result in the AS returning a
>     form to the browser that will be displayed to the user. Then the user
>     will presumably need to fill in that form and send it to the AS. And
>     this may involve a dialog of multiple exchanges. This will presumably
>     eventually end with a response from the AS containing a token. How does
>     the UA recognize this as the completion of the dialog?
> 
> In this specific case, take a look at the following flow in the RFC that 
> defines this mechanism:
> https://tools.ietf.org/html/rfc8252#section-4.1

I don't find that at all useful because it abstracts away all the useful 
bits. This implies an interface between the client app and the browser. 
What is that interface? Where is it defined? This is needed to implement 
a client app. Specifically:

- what information is passed in (1)? (Just the URL?) And how?

- what information does the client app expect back in (4)? How is it 
encoded?

- the figure shows just one round trip (2) and (3) between the broswer 
and the AS. Is that always the case? Doesn't this potentially require 
multiple round trips? How does the browser know it is time to return to 
the client app?

- is the SIP UAS that is requesting authorization (e.g. registrar) the 
token endpoint in figure 4.1?

>     In particular, does the UA need to know anything about the AS or the
>     authentication environment in which it is operating? Or is this
>     consistent across all types of AS?
> 
> The UA needs to know if it is an OAuth AS or and OpenID Connect server 
> to know to request access and refresh tokens only or in addition to ask 
> for an id token.

How does it know that? Isn't that a function of what the SIP UAS 
requesting authorization wants?

>     Also, I gather there can be different kinds of token in the
>     response. Is
>     this of concern to the UA? Or does the UA blindly pass the resulting
>     token on to the registrar, so that the registrar can decide what to do
>     with it?
> 
> The UA will only pass the Access Token to the registrar.
> The refresh token is used by the UA to obtain new access token from the 
> AS and will never be passed to any other entity.
> The id token is consumed by the UA only to get more information about 
> the user, e.g. SIP AOR.

None of this is clear from your draft.

Perhaps you could start by reproducing Figure 1 from 
https://tools.ietf.org/html/rfc8252#section-4.1 but changing the labels 
of the components to map them on to the elements in your draft.

>     Another point I want to follow up on is: you have now clarified that
>     the
>     authz-server-value contains a URL referencing the AS. Why not tighten
>     the syntax to specify the allowed value types?
> 
> Can you elaborate on what you mean "value types"?

Instead of defining the syntax as a quoted string, you could use ABNF 
for an HTTP/HTTPS URL. Or if you want it more general than that you 
could give generic URL syntax and use text to describe which kinds of 
URL are (and are not) suitable. (E.g. I imagine that SIP: and FILE: URLs 
are probably not suitable. I don't know what would be beyond HTTP and 
HTTPS.)

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
>     I presume you intend this
>     to be something that a browser can use to query the AS. The obvious
>     type
>     for this is an HTTPS URL. I am guessing that you are leaving this vague
>     to allow other types that might be supported by browsers and ASs. But
>     presumably there is something you can say about the properties expected
>     of this URL. I guess it ought to be something that is generally
>     supported by browsers, and that can be used to reference forms.
>     (E.g., a
>     SIP URL wouldn't be appropriate here.)
> 
>              Thanks,
>              Paul
> 
>      >
>      > Regards,
>      >   Rifaat
>      >
>      >
>      > On Sat, Oct 19, 2019 at 4:21 PM <[e-mail]
>     <mailto:[e-mail]>
>      > <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >
>      >
>      >     A New Internet-Draft is available from the on-line
>     Internet-Drafts
>      >     directories.
>      >     This draft is a work item of the Session Initiation Protocol
>     Core WG
>      >     of the IETF.
>      >
>      >              Title           : Third-Party Token-based Authentication
>      >     and Authorization for Session Initiation Protocol (SIP)
>      >              Authors         : Rifaat Shekh-Yusef
>      >                                Christer Holmberg
>      >                                Victor Pascual
>      >              Filename        :
>     draft-ietf-sipcore-sip-token-authnz-04.txt
>      >              Pages           : 14
>      >              Date            : 2019-10-19
>      >
>      >     Abstract:
>      >         This document defines a mechanism for SIP, that is based
>     on the
>      >     OAuth
>      >         2.0 and OpenID Connect Core 1.0 specifications, to enable the
>      >         delegation of the user authentication and SIP registration
>      >         authorization to a dedicated third-party entity that is
>     separate
>      >     from
>      >         the SIP network elements that provide the SIP service.
>      >
>      >
>      >     The IETF datatracker status page for this draft is:
>      > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/
>      >
>      >     There are also htmlized versions available at:
>      > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-04
>      >
>     https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-04
>      >   
>       <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-04>
>      >
>      >     A diff from the previous version is available at:
>      >
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-04
>      >
>      >
>      >     Please note that it may take a couple of minutes from the time of
>      >     submission
>      >     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>
>      >     <http://tools.ietf.org>.
>      >
>      >     Internet-Drafts are also available by anonymous FTP at:
>      > ftp://ftp.ietf.org/internet-drafts/
>      >
>      >     _______________________________________________
>      >     sipcore mailing list
>      > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/sipcore
>      >
>      >
>      > _______________________________________________
>      > sipcore mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/sipcore
>      >
> 
>     _______________________________________________
>     sipcore mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sipcore
>