It looks like Intel is entering into the personal data & big data narrative. Given that Intel owns a considerable chunk of the motherboard & SoC real-estate (think Processors, discrete TPMs, AMT, etc. etc), they do indeed have access to the plumbing of my machine.

One question is whether hardware and chipset providers will begin to require end-users to agree to Terms of Service (allowing them to access data bits moving around the board). Such a move would complicate the user’s life.  A typical person would then be forced to accept TOS and EULAs at three layers (at least):

• The hardware layer.
• The OS level (think EULAs)
• The application layer (think EULAs when installing Office productivity tools)
• The Services Provider (SP) and IdP layer (think Click-Thru agreement when signing-up to accounts)

After discussions during the presentation, I believe one of the technical issues that still causes confusion is the fact that UMA uses three (3) distinct OAuth2.0 Tokens:

• AAT Tokens: Authorization API Token — this OAuth2.0 token is used by the Client to prove (to the Authorization Server) that it has authorization to access the APIs at the Authorization Server.
• PAT Tokens: Protection API Tokens — this OAuth2.0 token is used by the Resource Server to prove (to the Authorization Server) that the Resource Owner (e.g. Alice) has provided it (the Resource Server) with authorization to register Alice’s resource at the Authorization Server.
• RPT Tokens: Requesting Party Tokens — this OAuth2.0 token provides authorization for the Requesting Party to access resources at the Resource Server.

Here are the key take-aways:

1. All three tokens are OAuth2.0 tokens.
2. All three tokens are issued by the Authorization Server (or what used to be called the Authorization Manager in UMA).
3. All three tokens should ideally be used in conjunction with the relevant parts of the UMA Binding Obligations (BO) spec. The BO spec tells the parties involved what their legal obligations will be.

The at the heart of his proposal is the notion of shifting the thought paradigm from the person as the absolute owner of his/her personal data to one where the person is seeking the right to know about who has his/her personal data, how they obtained it, what are they doing with it and to whom have they sold the data (the 4 questions).

Following on from Ray’s post and from Professor Sandy Pentland’s view on the New Deal on Data, I believe there should be a new market in the digital economy where individuals can meet directly with buyers of their personal data, and where individuals can opt-in to make more data about themselves available to these buyers.  Cut out the middleman — the big data corporations that are not contributing to the efficiency of free markets.

“Individuals and organizations utilize secure, efficient, easy-to-use, and interoperable identity solutions to access online services in a manner that promotes confidence, privacy, choice, and innovation.”

Identity Solutions will be:

• Privacy-enhancing and voluntary
• Secure and resilient
• Interoperable
• Cost-effective and easy to use

Today we had the privilege of hearing a presentation by Loius Wingers and Stefan Treatman-Clark on  a couple of lightweight ciphers from the NSA.  These are called SIMON and SPECK. The algorithms are not yet published, but they have a paper (pdf copy here) that shows some numbers on the performance of the proposed ciphers.

The SIMON and SPECK algorithms come in a family that range from 48-bits to 128-bits.  Since the target deployment area is low-power and low memory devices (i.e. RFID devices, etc), the requirement is that these algorithms do not use more than 2000 gates. The paper has a table showing the GE and throughput.

Louis and Stefan presented SIMON and SPECK at the 2013 Legal Hack-a-Thon and  the MIT Media Lab.

Ray Campbell argues quite elegantly and convincingly that the “data ownership” paradigm is not the correct paradigm for achieving privacy and control over personal data. The notion that “I own my data” can be impractical especially in the light of 2-party transactions, where the other party may also “own” portions of the transaction data and where they might be legally bound to keep copies of “my data”.

Instead, the better approach is to look at “transparency” and visibility into where our data reside and who is using it. Here are the four questions that Ray poses:

• Who has my data
• What data they have about me
• How did they acquire my data
• How are they using my data

Transparency becomes an important tool disclosure management of personal data. These questions could be the basis for the development of a  trust framework on data transparency, one which can be used to frame Terms of Service that both myself and the Relying Party must accept.

The definition of “client” in OAuth 2.0 (RFC6749) is as follows:

 An application making protected resource requests on behalf of the resource owner and with its authorization.

The UMA (draft-06) definition of the “client” is as follows:

 An application making protected resource requests with the resource owner’s authorization and on the requesting party’s behalf.

UMA makes the clear distinction between the “Requesting Party” and the Client (or the “Requester”). The Requesting Party is considered to be the human being (or organization, or a human legally representing an organization), while the Client in UMA is the “proxy” entity through which the Requesting Party accesses the resources hosted at the Resource Server. In the UMA view, Bob is the human person who is using the client but may not be in full control of all aspects of the client’s operation.

Nat Sakimura (from the OpenID Foundation) in his recent blog corrects the common misconception that ”many people seem to think that this client as “Alice” the resource owner.” I absolutely agree with this view.  However, in order to truly support a realistic Alice-to-Bob sharing, OAuth 2.0 needs to expand its definition and understanding of the client.

The following diagram illustrates further. In this diagram, Alice is wanting to let Bob access her calendar so that Bob could adjust his travel itinerary to match Alice’s itinerary. Alice is the owner of her resource (her calendar file) which resides at the Resource Server (operated by MyCalendardz.com). Bob is using the client (the application operated by Tripitz.com) in his desire to access Alice’s calendar file at the MyCalendarz.com. The client is therefore acting on behalf of Bob.

The OAuth 2.0 definition of “client” fails to recognize that a (legal) relationship may exist between the human person (Bob who is driving the “client” application at Tripitz.com) and the company called Tripitz.com.  Thus, in the Alice-to-Bob sharing, OAuth assumes that Bob is directly accessing the resources, whereas in reality Bob is more likely to be using his browser to “remotely manipulate” the client application (being operated by a third-party Tripitz.com) to access Alice’s resources at the Resource Server (MyCalendarz.com). The UMA architecture recognizes the real-world reality that Bob will likely need to have an account at Tripitz.com, in which Bob will be required to accept the Terms of Service (TOS) of Tripitz.com.

UMA recognizes (i) the Bob-to-Tripitz relationship and (ii) the Tripitz-to-CopMonkey relationship by requiring two (2) types of OAuth tokens to be presented/wielded by the client:

• The Authorization API Token (AAT):  this is the OAuth token that belongs to the client (TripItz.com) and which authenticates the client to the Authentication Server.
• The Requesting Party Token (RPT): this is the OAuth token that belongs to the Requesting Party (Bob) and which authenticates Bob to both the Authentication Server and the Resource Server.

This distinction between the Requester and the Requesting Party in UMA allows legal agreements (i.e. trust framework) to recognize Bob as distinct from Tripitz.com, and accord different legal obligations to these two entities. And from a risk management perspective, it allows finer grain analysis and risk assignments to these entities.

In summary, in order to address the true Alice-to-Bob sharing of resources, OAuth 2.0 needs to:

• expand its understanding of “client” to mean an application being owned and operated by a third party (not Bob).
• add another player to the ecosystem, namely Bob the Requesting Party.
• define that the client is acting on behalf of Bob.

(1) Proposed Membership Agreement

(2) Proposed Intellectual Property Rights Policy

(3) IDESG Rules of Association

Key Dates and Times

• Ballot on the Membership Agreement & IPR Policy opened at 12:00 noon ET on December 3, 2012
• Ballot on the Membership Agreement & IPR Policy will close at 12:00 noon ET on December 17, 2012