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

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 4 Jul 2014 13:21:55 +0000

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

---

From: Graham Klyne <[email-masked]>
Date: Sun, 06 Jul 2014 17:25:01 +0100

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:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 7 Jul 2014 09:40:04 +0000

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,
> 
> > The Open Mobile Alliance wishes to register the "acr:" URI scheme
> under the "provisional" registration tree.
> > 	    http://technical.openmobilealliance.org/Technical/technical-
> information/release-program/current-releases/rest-netapi-acr-v1-0.
> >
> http://member.openmobilealliance.org/ftp/Public_documents/ARCH/Permanent
> _documents/OMA-TS-REST_NetAPI_ACR-V1_0-20140701-D.zip
> >
> >

---

From: Graham Klyne <[email-masked]>
Date: Mon, 07 Jul 2014 11:24:16 +0100

OK, I get it now.  Thanks.

I'm not sure how useful this scheme would be in practice.  Have you looked at 
the ni: scheme (http://tools.ietf.org/html/rfc6920) - there appears to be some 
overlap.

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.

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.

Saying "search engines should avoid indexing these identifiers" doesn't really 
cut it here, IMO.

BTW, the document itself uses inconsistent appendix header numbering (or it 
shows inconsistently in OpenOffice).

#g
--

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 11 Jul 2014 13:25:49 +0000

Hi Graham,

Thanks for your review. Please find my responses / questions inline.

I have done some updates to the proposed URI definition (triggered by your comments as well as by some other comments received offline) which can be found in a marked-up copy of Annex H at    
http://member.openmobilealliance.org/ftp/Public_documents/ARCH/REST-NetAPI/2014/OMA-ARC-REST-NetAPI-2014-0053-CR_ACR_IANA_Registration_addressing_review_comments.zip  
(I have included a PDF variant this time).

Kind regards,
Uwe 

> Sent: Monday, July 07, 2014 12:24 PM
> 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").
 
> 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?
 
> 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

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.

> > 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
> >
> >
> >> Can't review without accepting licence terms that I don't have time
> to
> >> read and
> >> understand.
> >>
> >> #g
> >> --
> >>