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

[Christer Holmberg <[e-mail]>]

Paul,

Are you ok with the clarifications below?

We are trying to move the draft to WGLC, so we would appreciate if you could reply.

Regards,

Christer


From: sipcore <[e-mail]> on behalf of Christer Holmberg <christer.holmberg=[e-mail]>
Date: Wednesday, 30 October 2019 at 21.13
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-05.txt

Hi,

>I'm still struggling to understand what the expectations are of the UA
>in this process.
>
>IIUC, when the registrar/server/proxy generates a "Bearer" challenge
>specifying a particular AS, that implies that it has knowledge of that
>AS and how to deal with it. And it may well have relationships with
>multiple ASs, and challenge using them all. And there is an assumption
>that either UA or the *user* of the UA must have a relationship with at
>least on of the ASs to use for authentication.
Correct.

>My thought is that commonly the UA itself *won't* have a relationship
>with the AS. Rather it will expect the user to be the one to have that.
>In this case, can the UA have generic code that deals with any possible AS?
Yes. The interface between the UA and the AS is standardized.

>With web authentication I commonly experience an authentication popup
>that offers alternatives. (E.g., facebook or google or private local
>id/pw authentication.) The user then gets to pick one, and then
>authenticate with a corresponding AS. I am thinking the SIP process
>could be the same. The alternatives offered to the user would correspond
>to all the challenges (both Bearer and digest) for a single realm.
>
>Is this a use case you have in mind as being covered?
I assume that the registrar could offer multiple AS(s), and then the user chooses one that it has a relationship with. Especially if the operator is using 3rd party AS(s), like Facebook, Google etc.

However, the operator might also use its own AS (or have a relationship with a specific 3rd party AS), where the user relationship with the AS is part of the user subscription, and in that case the registrar most likely will only return that AS (because it knows the user has a relationship with it).

>(Of course, it may be that a UA is build to not depend on the user for
>authentication. In that case it must be preconfigured with credentials.
>But that isn't really no different from preloading the credential cache..
>And I guess it might be configured to only work with a single AS.)
>
>Based on your updates, I think I get it that the result from the AS to
>the UA access, refresh and possible id tokens, that only the access
>token is destined to be included in bearer credentials. The UA must know
>to use the refresh token to refresh its access token. And the UA may
>know to use the ID token for something (what?).  Is any of this
>knowledge AS-specific, or is it all generic?
It is part of the standardized OAuth procedures.

Regards,

Christer



> Regards,
>   Rifaat
>
>
> On Thu, Oct 24, 2019 at 8:52 PM <[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-05.txt
>              Pages           : 14
>              Date            : 2019-10-24
>
>     Abstract:
>         This document updates RFC 3261 and 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-05
>     https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-05
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-05>
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-05
>
>
>     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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sipcore
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>

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