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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 7 Mar 2020 12:58:55 -0500

Thanks Paul,

See my replies inline below.

Regards,
 Rifaat

On Sat, Mar 7, 2020 at 10:53 AM Paul Kyzivat <[email-masked]> wrote:

> Rifaat,
>
> Thanks for this update. It is improved.
>
> The new description of token types in section 1.3 is helpful. But then
> section 2.1.1 talks about some different token types: access tokens and
> refresh tokens. This seems to be a different dimension of token
> variation. Are these two independent dimensions?

Section 1.3 describes possible *representations *of tokens.
I will change the name of the section to Token Representation and update
the text accordingly.

> IOW, can access tokens
> be either structured or reference,

Yes

> and also refresh tokens be structured
> or reference?

No. Refresh token is only consumed by the AS, and it is usually a reference
token.

> It would be good to expand the discussion in section 1.3
> to cover all of this.
>
>
Will do.

        Thanks,
>         Paul
>
> On 3/7/20 6:11 AM, Rifaat Shekh-Yusef wrote:
> > All,
> >
> > We have submitted a new version that we believe addresses all the
> > comments received during the shepherd review.
> > Please, take a look and let us know if you have any further comments.
> >
> > Regards,
> >   Rifaat
> >
> >
> > On Sat, Mar 7, 2020 at 6:07 AM <[email-masked]
> > <mailto:[email-masked]>> 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-09.txt
> >              Pages           : 14
> >              Date            : 2020-03-07
> >
> >     Abstract:
> >         This document defines the "Bearer" authentication scheme for the
> >         Session Initiation Protocol (SIP), and a mechanism by which user
> >         authentication and SIP registration authorization is delegated
> to a
> >         third party, using the OAuth 2.0 framework and OpenID Connect
> Core
> >         1.0.  This document updates RFC 3261 to provide guidance on how
> >     a SIP
> >         User Agent Client (UAC) responds to a SIP 401/407 response that
> >         contains multiple WWW-Authenticate/Proxy-Authenticate header
> fields.
> >
> >
> >     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-09
> >     https://datatracker.ietf.
> .org/doc/html/draft-ietf-sipcore-sip-token-authnz-09
> >     <
> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-09
> >
> >
> >     A diff from the previous version is available at:
> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-09
> >
> >
> >     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>.
> >
> >     Internet-Drafts are also available by anonymous FTP at:
> >     ftp://ftp.ietf.org/internet-drafts/
> >
> >
> >     _______________________________________________
> >     sipcore mailing list
> >     [email-masked] <mailto:[email-masked]>
> >     https://www.ietf.org/mailman/listinfo/sipcore
> >
> >
> > _______________________________________________
> > sipcore mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: [email-masked]
Date: Sat, 07 Mar 2020 03:06:22 -0800

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-09.txt
	Pages           : 14
	Date            : 2020-03-07

Abstract:
   This document defines the "Bearer" authentication scheme for the
   Session Initiation Protocol (SIP), and a mechanism by which user
   authentication and SIP registration authorization is delegated to a
   third party, using the OAuth 2.0 framework and OpenID Connect Core
   1.0.  This document updates RFC 3261 to provide guidance on how a SIP
   User Agent Client (UAC) responds to a SIP 401/407 response that
   contains multiple WWW-Authenticate/Proxy-Authenticate header fields.

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.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 7 Mar 2020 06:11:15 -0500

All,

We have submitted a new version that we believe addresses all the comments
received during the shepherd review.
Please, take a look and let us know if you have any further comments.

Regards,
 Rifaat

On Sat, Mar 7, 2020 at 6:07 AM <[email-masked]> wrote:

>         Title           : Third-Party Token-based Authentication and
> Authorization for Session Initiation Protocol (SIP)

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 7 Mar 2020 10:53:31 -0500

Rifaat,

The new description of token types in section 1.3 is helpful. But then 
section 2.1.1 talks about some different token types: access tokens and 
refresh tokens. This seems to be a different dimension of token 
variation. Are these two independent dimensions? IOW, can access tokens 
be either structured or reference, and also refresh tokens be structured 
or reference? It would be good to expand the discussion in section 1.3 
to cover all of this.

	Thanks,
	Paul

On 3/7/20 6:11 AM, Rifaat Shekh-Yusef wrote:
>     https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-09
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-09>
>