Subject: Re: [Uri-review] Review request for Anonymous Customer Reference (acr:) URI scheme

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 12 Aug 2014 18:09:52 +0000

Hi Graham,

Thanks again for your comments.

Together with the co-authors at OMA, I have rewritten the grammar section to take your advice into account.
While doing this, we have also discovered and fixed some bugs.

The updated document can be found here:
http://member.openmobilealliance.org/ftp/Public_documents/ARCH/REST-NetAPI/2014/OMA-ARC-REST-NetAPI-2014-0053R01-CR_ACR_IANA_Registration_addressing_review_comments.zip 

Kind regards,
Uwe 

> -----Original Message-----
> From: ext Graham Klyne [mailto:[email-masked]]
> Sent: Sunday, July 13, 2014 10:42 AM
> To: Rauschenbach, Uwe (NSN - DE/Munich)
> Subject: Re: [Uri-review] Review request for Anonymous Customer
> Reference (acr:) URI scheme
> 
> On 11/07/2014 14:25, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
> >> I'm not sure how useful this scheme would be in practice.
> >
> > UR: If one takes actual use as an indicator of usefulness - the scheme
> is used in ~20 OMA RESTful Network APIs,
> > the GSMA OneAPI, and the GSMA RCS APIs.
> >
> > The basic problem this scheme tries to solve is that (telephone)
> network operators want to hide the actual telephone number
> > or SIP URI of their subscribers from third-party applications, still
> allowing the application to perform actions related to a
> > particular subscriber identified by that number or SIP URI. To solve
> this, the acr: URI contains a kind of pseudonym plus a hint
> > at a resolving authority. The pseudonym may be created from the user
> identity using a hash, but also by something else
> > (the draft lists "encrypted, hashed, represented by a look-up
> reference or otherwise obfuscated").
> 
> Fair enough.  My comment wasn't relevant for a provisional registration
> request,
> but I think some more substantive indication of utility on the open
> Internet
> would be appropriate if/when you consider updating to permanent
> registration.
> 
> >
> >> Have you looked at the ni: scheme
> (http://tools.ietf.org/html/rfc6920) - there appears to
> >> be some overlap.
> >
> > UR: Thanks for the pointer. The ni: scheme is indeed somewhat related
> to what we propose
> > (hashing is one way to create the obfuscated string), but it serves a
> different purpose.
> > It is focused on hashing, and requires to include which hash function
> was used to create a particular
> > obfuscated identity. Also, it does not allow to include a reference to
> a mobile network as authority.
> >
> > The "acr" scheme is intended to provide an obfuscated identifier
> string (no matter how it was created),
> > plus optionally a hint at a resolving authority such as Mobile Network
> Code or domain name.
> >
> > I have removed the example of hashing, as it may lead to the wrong
> conclusion.
> > As said, hashing is one option, but not the only or necessarily best
> one.
> >
> >
> >> I've only looked at appendix H.  I note it gives a complete ABNF
> >> specification rather than re-using parts of RFC3986, upon which it is
> claimed to be
> >> based. There's scope for divergence there.
> >
> > UR: Indeed. I however prefer that the ABNF is not spread over multiple
> documents,
> > so I propose to remove the reference to RFC 3986. Does this address
> your concern?
> 
> I wouldn't remove the reference.  It is in any case a requirement for
> any URI
> scheme that it is compatible with RFC3986-defined syntax.  While I
> appreciate
> that having syntax definitions spread over multiple documents can be
> inconvenient, re-using RFC3986 reduces the opportunities for unintended
> divergence.
> 
> A possible approach might be:
> 
> (a) where possible, use the syntax production structure and term names
> defined
> in RFC3986.  This alone would make it easier to see what additional
> constraints
> are imposed by this scheme.
> 
> (b) in the normative parts of the document, just define those elements
> that are
> specific to your scheme
> 
> (c) maybe provide an informational "collected syntax" section
> 
> #g
> --
> 
> 
> >
> >> A potential problem that occurs to me is with respect to discussion
> of
> >> using of
> >> hashes for anonymization.  It seems to me that the domain of
> potential
> >> values is
> >> potentially a lot smaller that the suggested SHA-256 hash space, and
> >> hence may
> >> be subject to a rainbow table attack to defeat the desired
> anonymization
> >> (http://en.wikipedia.org/wiki/Rainbow_table).  I understand this
> normal
> >> protection against this is to also include a "salt" (
> >> http://en.wikipedia.org/wiki/Salt_(cryptography) ).  I'm not a
> security
> >> expert,
> >> so I think you really should get this aspect of the proposal reviewed
> by
> >> people
> >> in the security community.  At the very least, I think this should be
> >> called out
> >> in security considerations in the template.
> >
> > UR: Good point. I have updated the security considerations.
> >
> >>
> >> Saying "search engines should avoid indexing these identifiers"
> doesn't
> >> really
> >> cut it here, IMO.
> >
> > UR: This text was inspired by corresponding text in the tel: URI
> definition,
> > http://tools.ietf.org/html/rfc3966. It is intended to provide an
> implementation
> > hint to search engines; however, I admit there is some doubt that they
> follow it.
> > I have remove this text in the updated version.
> >
> >> BTW, the document itself uses inconsistent appendix header numbering
> (or
> >> it shows inconsistently in OpenOffice).
> >
> > UR: thanks for pointing this out; I could however not reproduce this
> in Word.
> >
> >>
> >> #g
> >> --
> >>
> >>
> >> On 07/07/2014 10:40, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
> >>> Hi Graham,
> >>>
> >>> The draft for review is available from the OMA document repository
> >> (without any click-through license)
> >>>
> >>
> http://member.openmobilealliance.org/ftp/Public_documents/ARCH/Permanent
> >> _documents/OMA-TS-REST_NetAPI_ACR-V1_0-20140701-D.zip
> >>>
> >>> The Click-through license is only displayed when downloading
> documents
> >> from the OMA Release Program, which contains the published documents
> >> (and the draft this request is about is not published yet, in case
> >> changes are needed).
> >>>
> >>> Kind regards,
> >>> Uwe
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ext Graham Klyne [mailto:[email-masked]]
> >>>> Sent: Sunday, July 06, 2014 6:25 PM
> >>>> To: Rauschenbach, Uwe (NSN - DE/Munich)
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [Uri-review] Review request for Anonymous Customer
> >>>> Reference (acr:) URI scheme
> >>>>
> >>>> Sorry,
> >>>>
> >>>> Can't review without accepting licence terms that I don't have time
> >> to
> >>>> read and
> >>>> understand.
> >>>>
> >>>> #g
> >>>> --
> >>>>
> >>>> On 04/07/2014 14:21, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
> >>>>> Dear colleagues,
> >>>>>
> >>>>> The Open Mobile Alliance wishes to register the "acr:" URI scheme
> >>>> under the "provisional" registration tree.
> >>>>> I hereby kindly request review of this proposed scheme.
> >>>>>
> >>>>> Kind regards,
> >>>>> Uwe Rauschenbach
> >>>>>
> >>>>> --------------------------
> >>>>>
> >>>>> URI scheme name.
> >>>>> 	acr
> >>>>>
> >>>>> Status.
> >>>>> 	provisional
> >>>>>
> >>>>> URI scheme syntax.
> >>>>> 	See section H.1 in [1].
> >>>>>
> >>>>> URI scheme semantics.
> >>>>> 	The "acr" URI describes an anonymous reference that can be
> mapped
> >>>> to a resource or a
> >>>>> 	user or a group of resources or users.
> >>>>>
> >>>>> Encoding considerations.
> >>>>> 	The syntax definition above contains a complete enumeration
> of
> >>>> allowed characters, and
> >>>>> 	contains provisions for percent-encoding of unsafe
> characters.
> >>>>>
> >>>>> Applications/protocols that use this URI scheme name.
> >>>>> 	This URI scheme has been defined for use with the OMA
> RESTful
> >>>> Network APIs (see [1]).
> >>>>>
> >>>>> Interoperability considerations.
> >>>>> 	This URI scheme has been defined for use with the OMA
> RESTful
> >>>> Network APIs. Multibyte
> >>>>> 	character sets are not supported.
> >>>>>
> >>>>> Security considerations.
> >>>>> 	See section H.4 in [1].
> >>>>>
> >>>>> Contact.
> >>>>> 	Uwe [dot] Rauschenbach [at] nsn [dot] com
> >>>>>
> >>>>> Author/Change controller.
> >>>>> 	OMNA - Open Mobile Naming Authority of the Open Mobile
> Alliance
> >>>>> 	OMA-OMNA [at] mail [dot] openmobilealliance [dot] org
> >>>>>
> >>>>> References.
> >>>>> 	[1] OMA RESTful Network API for Anonymous Customer Reference
> >>>> Management,
> >>>>> 	    OMA-TS_REST_ACR-V1_0,_The Open Mobile Alliance.
> Published
> >>>> under
> >>>>>
> http://technical.openmobilealliance.org/Technical/technical-
> >>>> information/release-program/current-releases/rest-netapi-acr-v1-0.
> >>>>>
> >>>>> Note: Prior to publication, the latest draft version is available
> >> from
> >>>>>
> >>>>
> >>
> http://member.openmobilealliance.org/ftp/Public_documents/ARCH/Permanent
> >>>> _documents/OMA-TS-REST_NetAPI_ACR-V1_0-20140701-D.zip
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Uri-review mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/uri-review
> >>>>>
> >>>
> >
> > _______________________________________________
> > Uri-review mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/uri-review
> >