Re: WG Review: Secure Telephone Identity Revisited (stir)

I noticed in a few places the suggestion to replace telephone number 
with 'identity'.
I think that this is a particularly bad enhancement given how widely the 
term identity is understood by most people.
In RFC 6973 we defined the term (which is inline with many of the 
identity management efforts) as:
   $ Identity:  Any subset of an individual's attributes, including
      names, that identifies the individual within a given context.
      Individuals usually have multiple identities for use in different
      contexts.

I don't think that this is what the work is about.

Let's keep the charter text concise and enhance it later once work gets 
done.
Ciao
Hannes

On 08/21/2013 09:25 PM, Christopher Morrow wrote:
> + iesg
> -iesg-secretary
>
> On Wed, Aug 21, 2013 at 3:18 PM, Christopher Morrow
> <morrowc(_dot_)lists(_at_)gmail(_dot_)com> wrote:
> > On Wed, Aug 21, 2013 at 3:07 PM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> 
> > wrote:
> > > The following mostly are points that I raised within the group's mailing
> > > list discussion, during charter development.  In my view, they have not yet
> > > been adequately resolved:
> > >
> > >
> > > On 8/21/2013 10:52 AM, The IESG wrote:
> > > >     Please send your comments to the IESG mailing list (iesg
> > > > at ietf.org) by 2013-08-28.
> > > ...
> > > > The STIR working group will specify Internet-based mechanisms that allow
> > > > verification of the calling party's authorization to use a particular
> > > > telephone number for an incoming call.
> > >
> > > "use a particular telephone number for an incoming call" has no obvious and
> > it'd actually be kind of nice if the focus was NOT on the (us)
> > 10-digit "number", but instead on the 'identity' making the call.
> > There's a real chance to move beyond the '10-digit number' and to some
> > stronger, wider, richer sense of 'identity'... we should take that
> > opportunity and run with it.
> >
> > > unambiguous technical meaning.  In fact, it seems to imply the meaning of
> > > "authorization to call a particular number".  However of course that's not
> > > the intended meaning.  Since this is the only text in this paragraph that
> > > says what the working group will /do/ it should make its statement with
> > > clarity and technical substance.
> > >
> > > That is, the charter needs to use a precise term for specifying the specific
> > > role of the number of interest.  In earlier drafts, "caller id" was used.
> > s/number/identity/
> >
> > > The next sentence uses "source telephone number".  Perhaps that is
> > > acceptable.
> > no... focus on 'telephone number' is broken. Hell, it's not even
> > what's used in the phone system anyway... not really.
> >
> > > > Since it has  become fairly easy
> > > > to present an incorrect source telephone number, a growing set of
> > > > problems have emerged over the last decade.  As with email, the claimed
> > > > source identity of a SIP request is not verified, permitting unauthorized
> > >
> > > As a matter of form, I'll note the SIP's community's use of "identity" is
> > > what is called "identifier" in the identity community.
> > >
> > > ...
> > >
> > > > As its priority mechanism work item, the working group will specify a SIP
> > >
> > > Reference to work priority is only meaningful in the face of a list of tasks
> > > that will be considered simultaneously and what it means to give priority to
> > > one over another.  Based on the lengthy mailing list discussion of in-band
> > > vs. out-of-band, it appears that the current charter is actually intended to
> > > support simultaneous work on alternative mechanisms, rather than pursuing
> > > them sequentially.
> > >
> > > This should be made explicit.  If the requirement is to work on them
> > > sequentially, then state that.  If the intent is to work on both approaches
> > > simultaneously, then say that.
> > >
> > > ...
> > >
> > >
> > > > In addition to its priority mechanism work item, the working group will
> > > > consider a mechanism for verification of the originator during session
> > > > establishment in an environment with one or more non-SIP hops, most
> > > > likely requiring an out-of-band authorization mechanism.  However, the
> > > > in-band and the out-of-band mechanisms should share as much in common as
> > > > possible, especially the credentials.  The in-band mechanism must be sent
> > > > to the IESG for approval and publication prior to the out-of-band
> > > > mechanism.
> > >
> > > "in-band and the out-of-band mechanisms should share as much in common as
> > > possible"
> > >
> > > This is the essential text that mandates working on both approaches
> > > simultaneously and makes the earliet assertion about priority moot. (Note
> > > how far down in the charter this is buried, yet how fundamental a
> > > requirement is establishes.)
> > >
> > >
> > > ...
> > >
> > > > Input to working group discussions shall include:
> > > That's a lengthy list of documents.  Why has it left out other documents
> > > discussed during charter development and clearly of continuing interest to
> > > the effort, namely:
> > >
> > >     A proposal for Caller Identity in a DNS-based Entrusted Registry
> > >     (CIDER)
> > >     draft-kaplan-stir-cider-00
> > >
> > >     An Identity Key-based and Effective Signature for Origin-Unknown
> > >     Types
> > >     draft-kaplan-stir-ikes-out-00
> > >
> > >
> > > d/
> > >
> > >
> > > --
> > > Dave Crocker
> > > Brandenburg InternetWorking
> > > bbiw.net