For the content of the report, you can go directly to the section 3 of the release. In it, it talks about three topics:

1) Methods and approaches to user-friendliness

2) Utilization of information-providing organizations

3) Selection of disclosable information by consumers

The topic 1) is about how to show the users the nature of the personal data offering that they are making. Showing them 30pages ToS would not help, nor repeated consent dialogue would. It would just be a “click training” turning the internet dog into the Pavlov’s dog. We should suppress the consent dialogue whenever appropriate. For example, if the case falls into one of the “conditions for processing”, then, as one of the working group member advocated (not me), “the consent dialogue MUST NOT be shown.” (Now, this was too radical and did not quite made into the report, but I think it is something we need to explore.)

The report discusses what would be effective ways to convey what is important to the consumers, and give Information Sharing Label as an example. Further, it discusses about “iconified” version of it, since that would be even easier for the users, and would be able to overcome the language barrier.

The translated title of topic 2) is a bit misleading. At the first sight, you may think that it is talking about the attribute providers. It is not. It is talking about the metadata providers: metadata about the recipient of the personal data.

Consumer in general faces great deal of information asymmetry that they are unable to assess if the data receiver is trustworthy. A metadata provider, which is typically an entity that inspects the receiving entity in one way or another would be able to help them. It could be completely private sector, or could be blessed by the respective authority such as privacy commissioner. In a way, it is a privacy trust framework.

Item 3) is about letting the user select what attribute to share. Sounds familiar? Well, may be not. The proposal is to provide the consumer the purpose of the use for each attribute. That’s not very conventional. I have not seen many of them.

I would further argue that it should tell the consumer what is the consequence of data sharing, but that is not in the report.

Some of the things that did not quite made into the report (perhaps because the report writer was not there during the discussion) but I think is very important is about the direction of consent. In the real life that we live, it is reversed. We daily agree to companies’ terms of service and privacy policy, but that actually does not make sense because the entity that licenses the personal data is us, the consumer, and not the recipient. It is the corporations that has to agree to your licensing terms. Doc Searls’ “The Intention Economy” was also quoted in the working group. 

By the way, I am at the European Identity Conference this week, and so is Doc Searls. It might be a good opportunity to connect if you are at the EIC2013.

You surely must have seen this picture — InternetDog.jpg : On the internet, nobody knows you’re a dog.

Internet Dog. Peter Steiner’s cartoon, as published in The New Yorker.

This is a hard enough problem that we have long been trying to solve.

At the same time, to promote the identity federation and API economy, privacy problems also had to be solved, so identirati has long been trying to solve the privacy problems. Things like psudonymous identifier and partially unlinkable authentication etc. are prime example of such things. But above all, the most important thing is to how to get a meaningful consent and we have been trying to solve it. The consent screen you are so familiar with these days were actually created on the way.

Since a few years ago, however, I started to doubt if that is a good model. Do people read the consent screen? Do they read privacy policy and terms of service? Of course not. Then how could such a consent screen be meaningful? Are we not just training the users to click “accept”.

And here comes the “explicit consent requirement” that EU promotes. Oh, no. That’s a disaster.

We are now turning the Internet dog into Pavlov’s Dog.

Turning Internet Dog into Pavlov’s Dog – based on IIW dog.

We are doing the Pavlovian conditioning to the users to click “accept”. Then, the  attackers can easily hide the privacy attack in the forest of the seemingly benign privacy policy clauses and have the user click “accept”.

Actually, I would think that the current consent model is completely broken.

The direction of the consent is the reverse of what it should be.

It should be the service providers who agrees to the individual’s privacy policy because it is us who is letting them use our personal data.

One way of implementing it is to create a small set of consent like Creative Commons license. Typical one would be something like:

Minimal – No Share – Single Transaction (min-no-1 license)

standing for

• Minimal – minimal data (only the minimum amount of data is requested to fulfill the transaction)
• No sharing – do not give the data except for outsourcing to a data processor, in which case the data controller should have full responsibility for it;
• Single Transaction – The license to the personal data is valid only for this transaction thus once the transaction is complete and some required retention period has passed, the data will be deleted;

It can be graphical like

The user can set this preference in the identity provider. If the relying party / service provider agrees to it, the consent screen MUST NOT be shown. It removes the friction for the service provider, and prevents the user trained as a Pavlov’s Dog.

This way, if the consent screen type of thing appears, user will know that something unusual is happening and they should be very careful about it.

Now then, the problem becomes of the issue of whether the service provider tells a truth. For example in min-no-1 license, does the service provider really only asking for the minimum data?

There comes the assessor. Accredited assessor of a Privacy Trust Framework shall examine the request and determines if it complies to min-no-1 license. If it does, then s/he will sign the request file. Then, the service provider can register the location of the file to the IdP. The IdP fetches the file, validate the signature, and decide whether it is good for its user. If it determines so, it will let the request to come.

Is there a protocol that achieves it?

Yes. OpenID Connect. OpenID Connect has a facility for registering something called request_uri. This is exactly what is described above. So the technology is there. What we do not have is the policy template and the trust framework that assesses the service provider requests.

How does Alice share her protected resources (like medical test result) to Bob?

I may have bloged in the past, but here is another try.

The requirements:

1.  Alice needs to give permission to Bob to access her resource; 
2. The resource needs to be able to find out the fact that Alice has given the permission. (policy);
3. The resource needs to make sure the entity that accessing it is Bob;

Assumption:

1. Alice and Bob has OpenID Connect Identity provider (OP) of their own; 
2. The resource has been registered at Alice’s authorization server and the accounts at the resource and the authorization server is linked somehow.;
3. Alice has to know Bob’s identifier in Alice initiated flow, and Bob has to know Alice’s identifier in Bob initiated flow.

There can be two kind of work flow:

1. Alice initiated flow (Alice giving the permission to Bob and Bob access the resource); 
2. Bob initiated flow (Bob requests the claim; Alice approves it; Bob access the resource);

WF1: Alice initiated flow (Alice giving the permission to Bob and Bob access the resource)

This is an Alice initiated flow. In this workflow, it proceeds as follows:

1. Alice access the endpoint that let her create the policy / authorization (AM in UMA?) for Bob to access her resource;
2. Alice is redirected to her OP and gets authenticated and bounced back to the AM;
3. The AM shows Alice the URL that Bob can use to access the resource. (Note: URL may have the policy encoded in it so that the servers can be stateless) In Link-Rel terminology, the type of the resource (e.g., the medical test result) is ‘rel’ and the URL is the ‘link’;
4. Alice sends the URL somehow to Bob (e.g., email);
5. Bob access the URL;
6. Since URL is protected, Bob is bounced to his OP. (Note: At this point, the resource server has to be registered at Bob’s OP as a client.) ;
7. OP authenticates Bob and bounces him back to the registered redirect URI, say with ‘code’;
8. The resource accesses the token endpoint of Bob’s OP to get his ID Token;
9. The resource examines the ID Token and finds out that the person accessing is Bob through the ‘iss’ and  ’sub’ claim;
10. The resource returns Alice’s medical test result to Bob’s browser;

The trick here is the ‘link’. The ‘link’ has to contain some state information that can be used to look up the policy that Alice has set. It could either be completely encoded in the URI or the resource server may resolve the policy from the state. Apart from that, there is nothing special. It is just the standard OpenID Connect repeated twice; one each for Alice and Bob. Also, it would be worth noting that to achieve this, Alice somehow has to know Bob’s identifier, such as email so that Bob can prove that he is the legitimate holder of that identifier.

WF2: Bob initiated flow (Bob requests the claim; Alice approves it; Bob access the resource)

This is Bob initiated flow.

1. Bob does a lookup through Webfinger etc. to find out Alice’s AM endpoint;
2. Bob requests access to ‘medical test claim’ to Alice’s AM endpoint;
3. Since Bob is not authenticated, he is redirected to his OP. (He may have to chose one in the Account Chooser etc.) ;
4. The OP authenticates Bob and get him back to the endpoint with ‘code’;
5. The AM resolves ‘code’ and gets Bob’s ID Token;
6. The AM returns the page saying ‘Authorization Pending’ etc. with the link URL that he can use to access the resource once Alice authorizes.
7. The AM sends the notification to Alice with a link via email, SMS, etc. (SPAM is a problem here.) ;
8. Alice gets the notification and clicks on the link (AM).
9. The link (AM) bounces Alice back to her OP to get her authenticated after which she returns with a ‘code’;
10. The AM resolves ‘code’ to get ID Token and finds out that it is Alice;
11. The AM shows the authorization consent page to Alice;
12. Once Alice agrees, notification is sent to Bob.
13. The rest is the same as the WF1: Step 5 and after.

OK?

please be invited to submit a paper or abstract to the “Open Identity Summit”.
Furthermore we would be delighted to meet you at the picturesque Kloster Banz in September.

Please forward this mail to other colleagues, which might be interested in Identity Management, Open Source and Cloud Computing.

BR,
dh

************************************************************
Call for Papers – Open Identity Summit 2013
************************************************************
September 10th – 11th 2013, Kloster Banz, Germany
Deadline for electronic submissions: May 15th, 2013
************************************************************
The aim of Open Identity Summit 2013 is to link practical experiences and requirements with academic innovations. Focus areas will be Research and Applications in the area of Identity Management and Open Source with a special focus on Cloud Computing.
***********************************************************
More information: http://openidentity.eu
***********************************************************

The topics of the workshop include but are not limited to:
***********************************************************
Identity Management
***********************************************************

• Security, interoperability as well as legal, economic and privacy aspects of identity management, credential technologies and
• electronic identity tokens.
• Security analysis and proofs for authentication protocols and federated identity management protocols based on SAML, OpenID, WS-* and OAuth for example.
• Concepts for and practical experiences with components, systems, services, processes and applications for identity management.
• Novel identity management technologies, mobile aspects of identity management and alternative identity tokens.
• Identity management standards, interoperability aspects and interoperable identity management solutions.
• Provable secure identity management for cloud computing.
• International, global and long term aspects of identity management.

***********************************************************
Open Source
***********************************************************

• Security, interoperability as well as legal and economic aspects of open source in the area of security and identity management.
• Concepts and practical experiences with open source components related to security, identity management and cloud computing.
• Integration of identity management solutions in existing open source libraries or frameworks.
• Open source tools for distributed specification, development, quality assurance and dissemination of project results.
• Aspects related to open source community development and federated social media.
• New open source projects and news from existing open source projects in the area of security, identity management and cloud computing.

***********************************************************
Open Identity Partners
***********************************************************
*   Gesellschaft für Informatik e.V.
- BIOSIG – Biometrics and Electronic Signatures (www.biosig.org)
- CRYPTO – Applied Cryptology (fg-krypto.gi.de)
- PET – Privacy-Enhancing Technologies (fg-pet.gi.de)
- Regional Chapter Upper Franconia
*   FutureID Project (www.futureid.eu)
*   Open eCard Team (www.openecard.org)
*   BITKOM (www.bitkom.org)
*   CAST Forum (www.cast-forum.de)
*   Deutsche Wolke (www.deutsche-wolke.de)
*   European Association for eIdentity and Security (EEMA) (www.eema.org)
*   Open Cloud Initiative (OCI) (www.opencloudinitiative.org)
*   OpenID Foundation (www.openid.net)
*   Open Identity Exchange (OIX) (www.openidentityexchange.org)
*   Open Source Business Alliance (OSBA) (www.osb-alliance.de)
*   Open Source Integration Initiative (OSII) (www.osi-initiative.com)
*   SkIDentity Project (www.skidentity.de)
*   TeleTrusT (www.teletrust.de)
*   Trusted Cloud Program (www.trusted-cloud.de)

***********************************************************
Program Committee
***********************************************************
*   John Bradley (Ping, USA)
*   Arslan Brömme (GI/BIOSIG, DE)
*   Bud Bruegger (Fraunhofer IAO, DE)
*   Hartje Bruns (bos, DE)
*   Christoph Busch (CAST-Forum, DE)
*   Victor-Philipp Busch (Uni HH, DE)
*   Roger Dean (EEMA, UK)
*   Jos Dumortier (KU Leuven, BE)
*   Torsten Eymann (Uni BT, DE)
*   Hannes Federrath (Uni HH, DE)
*   Arno Fiedler (Nimbus, DE)
*   Lothar Fritsch (NR, NO)
*   Jens Fromm (Fraunhofer FOKUS, DE)
*   Walter Fumy (Bundesdruckerei, DE)
*   Ulrich Greveler (HS RW, DE)
*   Thomas Groß (UNEW, UK)
*   Oliver Hinz (TU DA, DE)
*   Olaf Herden (DHBW, DE)
*   Gerrit Hornung (Uni Passau, DE)
*   Moritz Horsch (TU DA, DE)
*   Detlef Houdeau (Infineon, DE)
*   Detlef Hühnlein (ecsec, DE)
*   Jan Jürjens (TU DO, DE)
*   Stefan Katzenbeisser (CASED, DE)
*   Andreas Kuckartz (W3C FSW CG)
*   Andreas Kühne (Trustable, DE)
*   Herbert Leitold (A-SIT, AT)
*   Luigi Lo Iacono (FH Cologne, DE)
*   Nils Magnus (LinuxTag, DE)
*   Tarvi Martens (SK, EE)
*   Pablo Mentzinis (BITKOM, DE)
*   Wolf Müller (HU Berlin, DE)
*   Anja Lehmann (IBM, CH)
*   Peter Lipp (TU Graz, AT)
*   Johannes Loxen (SerNet, DE)
*   Holger Mühlbauer (TeleTrusT, DE)
*   Alexander Nouak (Fraunhofer IGD)
*   Axel Nennker (DTAG, DE)
*   Sebastian Pape (TU DO, DE)
*   René Peinl (HS Hof, DE)
*   Sachar Paulus (FH Brandenburg, DE)
*   Henrich C. Pöhls (Uni Passau, DE)
*   Marco von der Pütten (bos, DE)
*   Kai Rannenberg (JWG Uni, DE)
*   Volker Roth (FU Berlin, DE)
*   Alexander Roßnagel (Uni Kassel, DE)
*   Heiko Roßnagel (Fraunhofer IAO)
*   Ahmad-Reza Sadeghi (CASED, DE)
*   Ivonne Scherfenberg (HPI, DE)
*   Johannes Schmölz (ecsec, DE)
*   Jörg Schwenk (RU Bochum, DE)
*   David Simonsen (WAYF, DK)
*   Tobias Wich (ecsec, DE)
*   Don Thibeau (OIDF, USA)
*   Thomas Uhl (OSBA, DE)
*   Thomas Wieland (HS Coburg, DE)
*   Alex Wiesmaier (AGT, DE)
*   Klaus-Dieter Wolfenstetter (DTAG)
*   Xuebing Zhou (Fraunhofer IGD, DE)
*   Jan Zibuschka (Fraunhofer IAO, DE)
*   Frank Zimmermann (Novartis, CH)

The essence of the entry is that, the definition of “client” in OAuth 2.0 (RFC6749) is too limiting and does not fit with many current use of the specification.

Here is the definition:

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

This excludes many useful cases. The client simply may not be acting on behalf of the resource owner, even though it may be doing something good for the resource owner.

The UMA (draft-06) definition of the “client” is much better:

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

Note that the “requesting party” is a defined term:

requesting party
An end-user, or a corporation or other legal person, that uses a client to seek access to a protected resource. The requesting party may or may not be the same party as the resource owner.

and also that “resource owner” is a defined term, and does not have to “own” the resource:

resource owner
An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end- user.

UMA (draft-06) definition of the “client” is much better than RFC6749. It is something that needs to be considered for an early revision or errata, IMHO.

In this -00 draft, I have just written down what I bloged in the past. Defining some additional relationships such as the public key etc. may be useful as well.

Have fun.

A new version of I-D, draft-sakimura-oauth-meta-00.txt

has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-meta
Revision:        00
Title:           JSON Metadata for OAuth Responses
Creation date:   2012-12-12
WG ID:           Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-meta
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-meta-00

Abstract:
This specification defines an extensible metadata member that may be
inserted into the OAuth 2.0 responses to assist the clients to
process those responses.  It is expressed as a member called “_links”
that is inserted as the top level member in the responses.  It will
allow the client to learn where the members in the response could be
used and how, etc.  Since it is just a member, any client that does
not understand this extension should not break and work normally
while supporting clients can utilize the metadata to its advantage.

There seems to be a very common misperception that in OAuth that the Resource Owner (the entity who gives permission for the resource access, aka “authorization”) and the client user at the resource access time is the same. It is plainly wrong.

In OAuth, there are two distinctive phases.

• phase 1: Permission Phase
• phase 2: Resource Access Phase

Permission Phase gets the access token to the (OAuth) client, while in Resource Access Phase, the client uses the access token to access the resource.

In “phase 1: Permission Phase”, typically, the Resource Owner delivers access token to the client directly (e.g., implicit flow) or indirectly (e.g., code flow). The Resource Owner will be both at the authorization endpoint and the client’s redirection endpoint.

In “phase 2: Resource Access Phase”, the client accesses the protected resource using the access token. Many people seem to think that this client as “Alice” the resource owner. This is not correct. It could be anybody who controls the client. If  and only if the client is used exclusively by Alice the resource owner, then we can safely assume that the user of the client is Alice. This is generally not true, especially when the client is a web service.

It is better to think of OAuth as Alice to Bob information sharing, where Bob is the controller/user of the client at the Resource Access Phase. There can be cases that Alice == Bob, but that is an exception.

At the same time, there is a question on what shall we do in the interim, before GSS-API support gets ubiquitous among the different clients.

In PEAFIAMP project, we are trying to address it as well.

The basic idea is to put the access token in the password field.

There are other pre-requisites such as:

1. Mapping the local user (e.g., mail user ) in the system to the federated user.
2. Federating the permission within the password length limitation.

The first issue is dealt at the first time account federation (on-the-fly provisioning). The service, e.g., MAIL provider, should provide a web interface to let the user federate the accounts.

Now that the email account is linked to the federated account, user can actually ask for the client specific “password (access token)”.

It starts with the MailWeb again. This time, the user goes to the get password page. There he inputs the name of the client that he can remember (e.g., “my iPhone”), and press the “request password” button. Since the MailWeb already knows the federated user, and thus the identity provider, it redirects the user to the identity provider with id_token as the user_hint.

Then, (if the user does not have the session) the user gets authenticated at the IdP, and instead of sent back to the site, the access_token is shown on the web page, which he is instructed to copy and paste to the mail user agent’s account settings.

The access token in this case is a pseudo-opaque string (TBD: if it can hold the IdP address, it will make it possible to use multiple identity providers) that acts as an artifact / reference to the permission list. When the mail server receives it and send it to the PAM module, the PAM module sends it to the token introspection endpoint at the IdP to get the validity and scope (read, read+send, (read+delete, read+delete+send)).

This scheme can also be used for other clients, such as SSH, or in the case of high performance computing platform, it may provide the PEM encoded X.509 certs as the access_token.

True, it is a hack. But it solves the current problems, till the proper way propagates.

Having this kind of capability aids the services to provide more aggressive special offers.

I had a discussion with Roland Hedberg today at the University of Umea and came up with the following:

1. Registration Endpoint Discovery
2. Offer registration API
3. Add Count API
4. Set Count API
5. Count get API
6. Offer deletion API

1. Registration Endpoint Discovery

We have to always bootstrap the process somehow: i.e., get the initial link. If the IdP provides this service, it MUST provide the following JSON at a .well-known/count_up_service. (Note: I am still debating whether I should go with JSON Schema or HAL. Here, I am using extended HAL, adding “method”and  ”Authorize” to signify HTTP method and HTTP Authorize header respectively. However, it is trivial to convert it to JSON Schema. The reverse, by the way, is not true – a reason to do it in HAL for the time being.)

{
  "_links":{
    "offer-registration-endpoint":{
      "href":"https://fully.qualified.url/of/offer_registration_endpoint{?offer_name,exp}",
      "method":"POST",
      "templated":true,
      "_properties":{
        "offer_name":{
          "required":true,
          "type":"String",
          "description":"User friendly name of this campaign/offer"
        },
        "exp":{
          "required":true,
          "type":"Datetime",
          "description":"Time expressed in YYYY-MM-DDTHH:MM:SSZ format."
        }
      }
    }
  }
}

2. Offer registration API

One of the basic requirement of the setting up of the “offer” is to register the offer meta-data to the server and obtain the offer identifier.It can be done by HTTPS POSTing the following parameters to the offer registration endpoint.

• offer_name REQUIRED. String that represent a user friendly name of the offer
• exp REQUIRED. Date and time representing the timing of the expiry of the offer. e.g., 2013-01-31T00:00:00Z

{
  "_links":{
    "_self"{
      "href":"https://fully.qualified.uri/of/offer_info_endpoint{?offer_id}, 
      "method":"GET",
      "Authorize":Bearer {access_token}"
    },  
    "add_count_endpoint":{
      "href":"https://fully.qualified.uri/of/single_countup_endpoint{?offer_id,id_token,n}",
      "method":"POST",
      "Authorize":"Bearer {access_token}",
      "templated":true,
      "description":"Add n the registered number for the entity that id_token maps.",
      "_properties":{
        "id_token":{"description":"id_token of the user in question."},
        "n":{
           "required":false,
           "type":"integer",
           "description":"A positive or negative integer to be added to the count of the user."
      }, 
    },
    "set_count_endpoint":{
      "href":"https://fully.qualified.uri/of/set_count_endpoint{?offer_id,n}",
      "Authorize":"Bearer {access_token}",
      "templated":true,
      "description":"Set the count for the user to n.", 
      "_properties":{
        "n":{"description":"An integer to which the count for the user is set to."}
      }
    },
    "get_count_endpoint":{
       "href":"https://fully.qualified.url/of/get_count_endpoint{?offer_id,id_token},
       "method":"GET",
       "Authorize":"Bearer {access_token}",
       "templated":true
    },
    "delete_offer_endpoint":{
       "href":"https://fully.qualified.url/of/delete_offer_endpoint{?offer_id},
       "Authorize":"Bearer {access_token}",
       "templated":true
    }
  },
  "offer_id":"string.representing.offer.id",
  "access_token":"string.representing.access.token"
}

Note that this information can always obtained from the URI in “self” relation returned here. It is idempotent.

3. Add count API, 4. Set Count API, 5. Count Get API

These shares the same response. The will let the server to identify the user from the id_token, then applies the operation to the record in the count registry that maps to the core-identifier of the user identified by id_token. For example, in the case of Add count API, it will be like:

SP->Add_EP: offer_id, id_token, n
Add_EP->Add_EP: Map id_token to the core user_id
Add_EP->Add_EP: user_id:count+=n
Add_EP->SP:n

The requests are defined in the response of offer registration API. So, we only need to talk about the response. In every case, the pseudonymous or anonymous user_id in the id_token will be mapped to the core entity id in the count up registry and the operation is applied to the record.

The successful response is the following JSON.

{
  "n":5, 
  "_properties":{
    "n":{"description":"The number of the count after the addition."}
  }
}

An error response would be like:

{
  "error_id":"invalid_token",
  "_properties":
    {
      "enum":["invalid_token","bad_request"]
    }
}

6. Delete Offer API

The final API is the Delete offer API. Again, the request is completely specified in the response stated in section 2., so I will just talk about the response.

Successful response would return HTTP code 200 with the following JSON in the body:

{
  "Status":"successfully deleted", 
  "offer_id":"offer id of the deleted offer"
}

Error resonse would be:

{
  "status":"no_such_offer", 
  "offer_id":"offer id of the deleted offer"
  "_properties":{
    "status":{
      "description":"signifies the status of the response.",
      "enum":["success", "no_such_offer", "bad_request", "invalid_token"]
  }
}