I have been dealing with this issue for many years, and have been blogging, speaking etc. for many years. (e.g., Identity 2.0 and Mydentity, Identity Loss with OpenID 2.0 ).

This is not a problem that technology alone can solve. It neither is a problem unique to OpenID. Any third party provided identity have this “feature.”

XDI.org has been dealing with it for many years. Last year, several OpenID provider shut down its services. However, some classes of OpenIDs survived it. They were members of XDI.org, where they escrowed user data etc. so that the transition from one service to another for the user was possible.

I think the OpenID community should start thinking about this kind of infrastructure more seriously.

Most popular reference to this idea may be OMB M04-04 and NIST SP800-63.

Essentially, it classifies the identities into four categories from Level 1 to Level 4, where Level 4 stands for higher assurance. For internet commerce, generally, Level 2 or so is required. This can be applied to third party provided identities as well, but the use of such identities over Level 2 seems to be quite rare yet. Some of the notable exceptions in the field of OpenID are Japan Airlines (JAL), Rakuten, and KDDI in Japan.

Part of the reason for the market for third party provided identity failing is information asymmetry. This can be addressed by such efforts like Open Identity Trust Framework (OITF) led by US ICAM that are implemented as Open Identity Exchange (OIX) and Kantara Initiative Identity Assurance Framework (KI-IAF) etc. . Open Reputation System would be another important piece for it.

OITF addresses another factor: Contract scalability problems. As you can easily see, if there are N parties in the picture, if the Contracts are to be negotiated peer-to-peer, there needs to be N*(N-1)/2 contracts. Clearly it does not scale. The way OITF solves this problem is to setup a Trust Framework Provider and everybody gets in contractual relationship with it rather than other parties. This would reduce the number of the contract to N and helps the scalability considerably. It is working for Level 1 as of now. However, doing so with Level 2 seems to be considerably harder. One of the pain point is that it is very difficult to define an appropriate separation of responsibility and liability and capture them into a standardized contract in a static manner.

Let me elaborate it a little more.

From the Relying Party (RP) point of view, just being told that the identity is Level 2 is not very useful. RP wants to know how much risk is associated in accepting the identity including how much the Identity Provider (IdP) is covering. For example, if the IdP says that the level of the confidence of the identity is 80% with variance of 2.9 and it is covering the damage up to US$100 if the identity turns out to be false, then the RP can make its decision on whether accepting it and authorizing the transaction or not much more easier and precisely than just being told that the identity is Level 2 because it can evaluate the risk. The figure can dynamically change as well. This should apply to private and public sector equally.

It may be an interesting topic to discuss at the The Berkman Center Law Lab’s Gov 2.0 Workshop: Governance as an Open Platform September 8

Related Article: Risk based security decisions and CX

http://smarterware.org/6286/how-to-set-up-openid-on-your-own-domain/

It is very good to hear that people turns out to like the “delegation[1]” feature.

In the article Gina says:

I’m not sure yet how to set Idproxy as my “fallback” provider just yet; if you know how to do that, post it up in the comments.

John Bradley posted a reply there, but the sanitization of the comment system seem to be eating up important portions and making it hard to use. So, here is my attempt to explain it.

How to set up OpenID for your domain with fallback provider

(1) Create an XRDS file like this:

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
  <XRD>
    <CanonicalID>http://xri.net/=!E18C.3B56.889D.850B</CanonicalID>
    <Service priority="10">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <URI>https://authn.fullxri.com/authentication/</URI>
      <LocalID>http://xri.net/=!E18C.3B56.889D.850B</LocalID>
    </Service>
    <Service priority="20">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <URI>https://www.google.com/accounts/o8/ud?source=profiles</URI>
      <LocalID>http://www.google.com/profiles/sakimura</LocalID>
    </Service>
  </XRD>
</xrds:XRDS>

In it, each <Service> represent different authentication service.
In the above case, I am using Google as my failover authentication service (priority="20″) and fullxri as the second service (priority="10″) .

(2) Put the link to this file by inserting the following to the top page of your domain (You need to replace my domain to yours.

<meta http-equiv="X-XRDS-Location" content="http://www.sakimura.org/yadis.xml"></meta>

That’s all!

Unfortunately, not all RP libraries can to this failover. DotNetOpenAuth and JanRan’s library supports this feature.

[1] It is the delegation of the authentication service, not the delegation of your authorization decision.

Also, the scope may require dynamic input parameters. The current spec draft does not specify it either. In fact, scope is nothing but the input parameter for the access_token right now.

The better approach, IMHO, is to define a generic way of what has been requested, instead of just defining proprietary “scope” strings.

For example, instead of defining an Authorization Server specific scope string for “Contact/Home”, define it as a generic registered string, such as “og”, so that one can specify it as

“og:email”,
“og:phone_number”,

etc. This is a much more granular way of giving permissions.

This has a side effect:

* The requests are longer

This is the rationale for having “request_url” for the flows.
One can put all the extension parameters in the “request_url”.

Some basic design principles:

• No name space through type URI: fixed registered string for extensions.
  e.g., for Open Graph, perhaps use og:variable_names OR og_variable names
  where either “og:” or “og_” is the type prefix. (I kind of prefer ”:” over “_” as
  a separator since in CGI “-” and “_” will be identical, and in PHP GPC parameters
  ”.” and “_” are identical. Also, we are using “_” in the variable names already. )
• No cross interactions with other extensions

I think it should be added as Chapter 7 or so, which means Security Considerations will be chapter 8.

Following is the strawman.

Simple, is it not?

For this to work out, there has to be a register of the prefix so that it will be unique. Where should the registry be is a good question.

One approach is to create a separate spec that lists all the OAuth extension prefixes.

I have further simplified the flow by talking to Breno and John.

Here it is:

(Fig. XX)
How is that?!

The major difference between Web App Profile is that it creates a request file that captures all the parameters in JSON format at “request_url”. Then, instead of sending parameters over the redirect, it sends this “request_url” over the redirect. The rest is more or less the same.

Here is a suggested text:

3.11 Mobile Web App Flow

The moble web app flow is a user delegation flow suitable for clients
capable of interacting with the end-user’s user-agent (typically a
web browser) that are capability constrained especially for url length
and capable of receiving incoming requests from the
authorization server (capable of acting as an HTTP server).

The mobile web app flow illustrated in figure XX includes following steps.

1. The web client creates a request file at a URL “request_url” that captures
   all the parameters that it would like to send to the Authorization
   Server including client identifier
   and a redirect URI to which the authorization server will send
   the end-user back once authorization is received (or denied).
2. The web client initiates the flow by redirecting the end-user’s
   user-agent to the end-user endpoint with rul.
3. The Authorization server obtains parameters by accessing request_url.
4. The authorization server authenticates the end-user (via the
   user-agent) and establishes whether the end-user grants or
   denies the client’s access request.
5. Assuming the end-user granted access, the authorization server
   redirects the user-agent back to the client to the redirection
   URI provided earlier. The authorization includes a verification
   code for the client to use to obtain an access token.
6. The client requests an access token from the authorization
   server by including its client credentials (identifier and
   secret), as well as the verification code received in the
   previous step.
7. The authorization server validates the client credentials and
   the verification code and responds back with the access token.

3.11.1 Client Prepares a Request file at request_url

Clients creates and saves the parameters in 3.6.1 at request_url.
This file can be used many times, so it does not need to be done
every time.

3.11.2 Client Requests Authorization

In order for the end-user to grant the client access, the client
sends the end-user to the authorization server. The client
constructs the request URI by adding the following URI query
parameters to the end-user endpoint URI:

request_url

Request file url from which the Authorization Server may
obtain the request parameters.

immediate

OPTIONAL. The parameter value must be set to “true” or
“false”. If set to “true”, the authorization server MUST NOT
prompt the end-user to authenticate or approve access.
Instead, the authorization server attempts to establish the
end-user’s identity via other means (e.g. browser cookies) and
checks if the end-user has previously approved an identical
access request by the same client and if that access grant is
still active. If the authorization server does not support an
immediate check or if it is unable to establish the end-user’s
identity or approval status, it MUST deny the request without
prompting the end-user. Defaults to “false” if omitted

The client directs the end-user to the constructed URI using an HTTP
redirection response, or by other means available to it via the end-
user’s user-agent. The request MUST use the HTTP “GET” method.

For example, the client directs the end-user’s user-agent to make the
following HTTPS requests (line breaks are for display purposes only):

GET /authorize?request_url=hhttps%3A%2F%2Fclient%2Eexample%2Ecom HTTP/1.1
Host: server.example.com

If the client has previously registered a redirection URI with the
authorization server, the authorization server MUST verify that the
redirection URI received matches the registered URI associated with
the client identifier.

The authorization server authenticates the end-user and obtains an
authorization decision (by asking the end-user or establishing
approval via other means). The authorization server sends the end-
user’s user-agent to the provided client redirection URI using an
HTTP redirection response, or by other means available to it via the
end-user’s user-agent.

3.11.1.1. End-user Grants Authorization

Refer to 3.6.1.1.

3.11.1.2 End-user Denis Authorization

Refer to 3.6.1.2

3.11.2. Client Requests Access Token

The client obtains an access token from the authorization server by
making an HTTPS request to the token endpoint. The client
constructs a request URI by adding the following parameters to the
request:

client_id

REQUIRED. The client identifier as described in Section 3.1.

client_secret

REQUIRED if the client identifier has a matching secret. The
client secret as described in Section 3.1. If it is used, the
request method MUST be “POST”.

code

REQUIRED. The verification code received from the
authorization server.

secret_type

PTIONAL. The access token secret type as described by
Section 5.3. If omitted, the authorization server will issue a
bearer token (an access token without a matching secret) as
described by Section 5.2.

The authorization server MUST verify that the verification code,
client identity, client secret, and redirection URI are all valid and
match its stored association. If the request is valid, the
authorization server issues a successful response as described in
Section 3.3.2.1.

If the request is invalid, the authorization server returns an error
response as described in Section 3.3.2.2 with one of the following
error codes:

o “redirect_uri_mismatch”

o “bad_verification_code”

o “incorrect_client_credentials”

Changes

• (2010-05-27) s/rurl/request_url/g

I hoped to prepare more, but with the current ill-health, this probably is the most I could.

Here is the new version of OpenID Artifact Binding (AB) .

Repository: http://bitbucket.org/openid/ab/

Browser Friendly Cache: HERE

For those of you who do not know, OpenID/AB is a chartered Working Group at the OpenID Foundation, and aims to create another binding for OpenID, so that it is

1. More Secure so that it can go all the way up.
2. Browser URL length limit friendly.

In addition, we have been targeting to make it

1. Very easy to write libraries, only with standard libraries
2. Very easy to implement for RP. For lower assurance RPs, it should be just a matter of pasting a javascript snippet, and a link.
3. Highly scalable: Completely stateless so that it can scale

I think the goal has been achieved as of draft 06.

It is using OAuth2.0 as the base protocol, and is building identity layer on top of it. Unlike David’s OpenID Connect straw man, it is not overloading the access token of OAuth2.0, so we can use that as OAuth token even for this OpenID flow.

I have implemented it myself (not being a professional programmer, it took more time than it should - besides, it was the first time for me to write anything in Javascript, and how-do-I-debug it???) in couple of days, in Javascript and PHP.

The size of the code shows how easy it is.

OP (PHP): 251 lines including debug codes and comments, as well as HTML.
RP (PHP): 109 lines including debug codes and comments, as well as HTML.
Magic Signatures Library: 83 lines including documentation.
AES Encryption Library (wrapper): 30 lines.

So, in total, it is 373 lines including documentation and debug codes.

AND: it supports asymmetric signature for non-repudiation, completely stateless OP, and my (proprietary version of) attribute exchange.

You can test drive them here: TEST DRIVE

Nice thing about what I did here for the attribute exchange is that the relying party can ask what combination so ever that the RP wishes of any of the attributes supported by the user. It is just a matter of making a “Request Parameter File”, which looks like this.

{
“ns”:"http://specs.openid.net/auth/2.0″,
“mode”:"direct_checkid_setup”,
“client_id”:"http://rp.tonescape.net/”,
“claimed_id”:"http://specs.openid.net/auth/2.0/identifier_select”,
“identifier”:"http://specs.openid.net/auth/2.0/identifier_select”,
“redirect_url”:"https://openid4.us/rp/rp.php”,
“atype”:"openid2json+sig”,
“ns:ax”:"http://openid.net/srv/ax/1.0″,
“ax:mode”:"fetch_request”,
“ax:avatar”:"”,
“ax:nickname”:"”,
“ax:lastname”:"”,
“ax:firstname”:"”,
“ax:gender”:"”,
“ax:birthyear”:"”
}

By change the “ax:lastname” to “ax:lastname#ja_Hani_JP”, I can get her Kanji name as well. It is that simple.

Not only that, you can push the write the attributes as well.
Just change “fetch_request” to “store_request”, and provide values to the attributes.

I have not implemented the following features yet, but should not take too much time.

• immediate: it should add only a few lines of code…
• payload encryption: Now that the encryption lib is done, it should be simple

Perhaps you can help .

This is a reply to: http://eternallyoptimistic.com/2010/04/20/xauth-first-take/

XAuth seems to be nothing but a shared cookie, so it may not be a single point of failure. The RPs do not seem to communicate with the xauth.org so it should not be a critical problem even if the server was failing. At the very worst, the RP has to show all the NASCAR icons. That is all.

At the same time, it would have an interesting (not fun) security implications on a shared computer, but I have not done the analysis yet.

And right, I feel that it is taking user out of the cycle as well. It would have been much better if it just points to the location of the user’s XRD/s that lists all the services that a user can edit, but that may be way too esoteric. I agree that it is not user centric. It is service centric in philosophy, but that may be what the user is asking as a priority: “ease of use”.

Due to an ever-increasing workload I must ask that each request be sent in a separate e-mail message unless related to a single, multi-part specification. As a reminder, a chart showing exactly what needs to be included with each request can be seen here:
http://docs.oasis-open.org/templates/MindMaps/TCAdminRequestNotices/index.html

To ensure the quickest possible handling of your request, make sure to
1. review the checklist: http://docs.oasis-open.org/templates/QAChecklistV3.html
2. Include the requisite information in the request:
http://docs.oasis-open.org/templates/MindMaps/TCAdminRequestNotices/index.html
3. do not include more than 1 document in any single request.

Thank you for understanding.

Regards,

Mary

Lucky thing is that it is trivial to create an Mobile friendly profile / binding of OAuth Wrap, since it is almost done. It suffices just to introduce a request artifact.

Here is the flow:

(fig.1) Wrap Mobile Web Profile

Of course, details need to be nailed down, but the basic flow should be it.

People may criticize that it introduce state in the AuthzServer. It may, but it is not necessarily so. Since the AuthzServer knows what it can serve, it has constrained set of scope and may well be able to encode it into an Artifact, so that it does not need to keep the state.

–
(Feb 12) Fixed typo in the figure.

1. Send CX proposal as an additional parameter on the Verification Code Request. Use wrap_client_id as the proposer’s identifier.
2. On the PoP verification page, display the terms and conditions included in the proposal.
3. Create the Verification code from the signature of the proposal and some nonce and random.
4. Web App Client sends the proposal again as an additional parameter on Access Token Request.
5. Sign the proposal to create the contract, serialize it with Base64 without line end, and return it as the access token on Access Token Response.

That’s all.

The answer is that we use 80 bytes in the fixed string:

?openid.ns=http://specs.openid.net/auth/2.0&openid.mode=art_res&openid.artifact=

Suppose we use 400 bytes in Artifact. Then, the total is 480 bytes.
That leaves 32 bytes to the non-query portion of the URL.

There however is one thing that these specs are missing. The Script types and the language.

Unlike most Western language, some language like Japanese have many scripts within itself. For example, we use “Kanji”, “Katakana”, “Hiragana”, “Romaji (alphabet)” as four distinctive scripts. Often, we are required to supply name and address both in Kanji and Katakana or Hiragana, because without Katakana or Hiragana, you really do not know how to pronounce the Kanji in many cases.

Thus, while it would probably suffice to express fullname just as

http://axschema.org/namePerson

in English, we need these in each scripts.

The problem is how to express these as Type URIs.

One obvious way of approaching it would be something like

http://axschema.org/namePerson#script_name/language_code

where script_name and language_code are optional.

For example,

http://axschema.org/namePerson#kanji
http://axschema.org/namePerson#katakana

would be the Kanji and Katakana version of the fullname.

If the default language for those were not specified, we could further qualify them as

http://axschema.org/namePerson#kanji/ja_JP

If there is only one script for the language, or if it does not matter, we could abbreviate like:

http://axschema.org/namePerson#/en_US

which is the same as

http://axschema.org/namePerson

if the default language was specified as en_US.

What would you think?

This article describes the concept of (abstract) Contract Exchange, and then discusses the OpenID Binding and Use of the Contracts as Access Tokens. At the end, it also provides a mapping table to User Managed Access (UMA) Terminologies.

About Contract Exchange

Contract Exchange (CX) is a protocol to exchange the signed contract dynamically among the entities in the network. It uses Public Key based signature, so it achieves certain degree of the non-repudiation and ability to prove. Thus, e-commerce etc. should benefit from it. In addition, since it can capture the purpose of the use, condition of the use, provisioning method etc. for the data/attributes, it can be used to achieve the server to server exchange of the data.

Draft OpenID CX is a binding of this Contract Exchange onto OpenID. It takes a form of OpenID Extension. Thus, it can be used over the existing OpenID Authentication 2.0, which is a GET/POST binding, as well as over the artifact binding which has been discussed since last fall. For the exchange of the proposal and contract etc., it is also using Attribute Exchange 1.1 Draft.

Basic Flow of the CX.

The basic flow of the CX has the following flow. Note that this is before binding it to a specific underlying protocol.
In the below, AM stands for Authorization Manager, SP for Service Provider.

1. (SP finds Proposal Template from XRD/S of the AM)
2. SP obtains the proposal Template from the AM.
3. SP specifies the variables in the Proposal Template to create a Proposal.
4. SP signs the Proposal to create a Signed Proposal.
5. SP sends the Signed Proposal to the AM.
6. AM shows the conditions to the user and obtains the authorization.
7. If OK, the AM counter-signs the proposal to create a Contract.
8. AM saves the Contract and sends a copy to the SP.
9. SP uses the Contract to obtain data etc. and provides service to the user.

The service does not necessarily require data transfer. It may even not a service over the network.
However, it is expected that in majority of the cases, it will be a network based service that requires some data transfer.
Under such circumstances, some data transfer protocol needs to be defined in the contract. e.g., OpenID AX, OAuth, Wrap “API Calls”.)

Characteristics of the CX Template

CX Templates has several unique features.

• XML is the default format.
• The template has to have a URL of the form http://uri_of_contract_template#digest_algorithm:digest, so if the template is changed, the url will also change.
• Anyone can create a template, but since AM is the party that knows what data is available as well as the party which creates the permission page, AM seems to be the natural place.
• As the result of the Hashed URL, template cannot be edited. Thus, we have to use variables to express the portion which is given from the outside.
• Template variables are expressed in the form of {{variable_name}}. As the variable name, xs:id of the XML element is used, and the value will be the inner text of the Element.

Characteristics of the CX Contract

• There can be as many parties as one wants. That is, we can express n-party contract. Each Party has Obligations.
• A Contract includes the public key of the each Parties. These can be used for the signature verification and data encryption.
• A Contract includes a TemplteURL and a Template. Ops and RPs can use this TemplateURL to figure out what kind of template it is.
• Obligation can be written in the Contract. This includes the price and damage limit.
• As a default data request method, AX Request is supported. Other format can be defined.
• Signature is done by XML Signature. Canonicalization is Exclusive Canonicalization. Since it is using the Digital Signature, the ability to proof is high even outside the system.

OpenID GET/POST Binding

CX can be bound to OpenID through GET/POST Binding and Artifact Binding. For the purpose of this article, which binding to use is a non-issue, so I am using simpler GET/POST binding flow.

In the next diagram I am using OP (OpenID Provider) instead of AM and RP (Replying Party) instead of SP to match the OpenID terminology. In addition, UA stands for User-Agent (e.g., Web Browser).

Data Transfer using CX

In the use case that transfers data, CX Contract can be used as either the holder-of-key or bearer access token by the RP. Alternatively, if the Data Provider has the copy of the contract, then ContractID can be used as a bearer token. (In general, AM and DP are different, so the later cannot be assumed in every case.) Using such Tokens, server to server data transfer can be achieved. Data Provider (DP) checks the authenticity of the contract and then creates a dataset and encrypts it with the public key in the Contract and provides it to the requestor. Since it is encrypted by the public key of the intended recipient, it cannot be read by somebody else.

Appendix 1: Mapping to UMA terminology

Hope the spec to include such instead of legacy ascii diagram…
websequencediagrams.com source would do.

Notes:

1. wrap_client_id and wrap_client_secret are provisioned from the AuthzServer to the WebAppClient in advance.
2. An Access Token is an opaque string whose format is agreed upon between the Resource and AuthzServer. It acts as a Bearer Token.
3. All the communication is done over HTTPS so signatures are said to be unnecessary. (I am skeptical on it though. [*1])

[*1] Security Questions

It might be because I have not spent too much time on this protocol, and I was writing this (original Japanese version) at 2:00AM, I have some questions on the security characteristics.

1. UA may act as the man-in-the-middle to tamper the request. (e.g., when the UA is infested by a malware.) To me, it seems that it can only be coped by either the request to be signed or something like an Artifact is used instead of the request itself. Since the target of WRAP is to remove the signature, the Artifact seems to be the way to go.
2. To identify the client, it is using client_id and client_secret. It is essentially a username/password authentication. Thus, from the NIST SP800-63 like perspective, it is only LoA1.
3. Access Token is another long-term secret. Moreover, it is revealed to somebody else than the client and the verifier (AuthzServer). It has some implication from the SP800-63 perspective.
4. MITM is possible even for HTTPS. How to recognized that the counter party is the right one needs to be specified in more details. Certificate Chain verification is only a necessary condition. If it is not done correctly, it will be possible to mount token capture and replay attack.
5. Access Token is specified only as an Opaque String. This actually needs to be specified a little more in detail. For example, randomness requirements, signature requirements etc. are needed to thwart the guessing attack and the access token forgery.
6. Browser Swap / CSRF attack has to be thwarted.

Much of these needs to be dealt with Section 7. Security Considerations.

In addition, I have not understood

1. Why are we provisioning wrap_client_id and wrap_client_secret out of band? The y can just be Subject and Pubkey of XRD. If we do so, the long-term client_secret problem disappears, though signature resurfaces.
2. Why do not we standardize on Scope format? For AuthzServers, having no standard is ok, but for WebAppClients, it is much easier to code on the standard than code a proprietary request per AuthzServer.

Various people have been working on this, such as IDIB efforts and some Infocard integration, but to me, there seems to be even simpler solution.

I have been wondering why nobody proposes this.
It is extremely simple.

Simply add your OP Identifier to the end of User Agent string, separated by semi-colon. For example, if you are using Safari, and if your OP is mixi.jp, then it would be like:

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9.1;op=mixi.jp

Creating custom header in IE is a bit of problem, but the UA string is an exception and can be changed just by changing a registry entry as far as I know. Most other major browsers provide ways to set the user agents.

The RP, upon receipt of the above string, extracts mixi.jp and redirects user to mixi.jp automagically. If he has a session there, which is likely, he may be returned to the site immediately.

True that it reveals your OP to every site. Some people may consider it a privacy problem, and some would complain about the security implication, but how real would be an attack using that information? Not much, I think. Anti-Phishing? It should be dealt with other mechanisms.

I am glad to write that OpenID Foundation Board has approved the change in the OpenID Process document so that a working group can be started without membership vote.

The change itself requires membership vote, so the notice will go out soon, and it is a month or more away for the new process to get effective, but once that is done, we can spin up WGs pretty quickly. That would certainly help AX 2.0, Auth 2.1 etc.

It is about this entry ”Is OpenID User Centric?”.

Johannes’s comment that OpenID being “http://netmesh.info/jernst/digital_identity/is-openid-still-user-centric” is very apt. This is one use case that OpenID is supposed to serve.

The other use case that it is serving right now is the Web SSO.

As a “personal/business card”, you do not need privacy. You do not want privacy. You want to reveal that it was you, and you want to be tracked.

In Web SSO case, you might or might not want to be tracked.

For User Centric thing, I believe that the user should control one’s XRD. Then, I can use Yahoo! or Google as authentication service that provide PPID.

If I want to preserve anonymity, I would use OP identifier to Yahoo! or Google. Alternatively, I could provide an XRD address that service PPID, but that would be a tall order for most people.

If I want to leave my track, then I will provide my (signed) XRD address.

As to the email as attribute being sent…

I think we should define contact service just like XRI people do. It could be email, twitter, or authenticated something, etc. The service should be advertised in the XRD. Then we should not need to provide “physical” address like email to the RP.

Today, I want to report the following:

OpenID BizDay #4

Date: Sept. 25, 2009 (Fri) 14:30 - 16:30
Venue: Vila Fontaine Shiodome Meeting room 2,3
1-9-2 Shinbashi, Minato-ku, Tokyo 105-0021
JAPAN
http://www.sumitomo-rd.co.jp/vf/shiodome/conference/map.html

Program:
“Application of OpenID at NTTCom”
Kazuhiro Kitamura, General Manager, Net Business Div.
NTT Communications Corp.

“gooID that grows with customers”
Yasushi Tsuruki, Manager, Service Dept., Media Div.
NTT Resonant Inc.