Re: [community] from W3C….Fwd: Proposal: "User" header field
Melvin Carvalho
melvincarvalho at gmail.com
Wed Dec 25 17:42:48 UTC 2013
On 25 December 2013 18:14, Phil Hunt <phil.hunt at oracle.com> wrote:
> Do you mean a URL for session state or a URL for the User (subject)
> authenticated?
>
The URL for the User (subject) authenticated.
>
> Phil
>
> On Dec 25, 2013, at 6:50, Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
>
>
>
>
> On 19 July 2013 16:00, n-sakimura <n-sakimura at nri.co.jp> wrote:
>
>> Actually, in the pure sense, OAuth Bearer Authorization is just
>> representing the Authorization = Access Grant, and the entity who is
>> presenting the token is not necessarily the entity who got authenticated
>> and obtained the token. That's the beauty of bearer instruments [1]. (Most
>> common bearer instrument is physical money such as bank notes and coins.)
>> It makes the late binded delegation / power of attorney easy.
>>
>> However, this feature makes the bearer token a dangerous thing to use as
>> authentication / representation of identity. To use it as an authentication
>> token, the following assumptions MUST be fulfilled.
>>
>> 1. Bearer Token is naver used by any entity but the entity who
>> obtained it.
>>
>> 2. It is possible to verify the audience of the token.
>>
>> These conditions are generally not met.
>>
>> That's why OpenID Connect introduced ID Token, which is a registered
>> instrument rather than a bearer instrument.
>>
>> If you were just concerned with authentication (= process of identifying
>> the entity in front of your service), then I would stick with OpenID
>> Connect. Create an OAuth authorization request with scope=openid as:
>>
>> https://server.example.com/authorize?
>> response_type=code
>> &client_id=s6BhdRkqt3
>> &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
>> &scope=openid
>> &state=af0ifjsldkj
>>
>> Then, you will get an authorization code.
>>
>> Send the authorization code to the authorization endpoint. This is a
>> plain OAuth 2.0 Authorization request again:
>>
>> POST /token HTTP/1.1
>> Host: server.example.com
>> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>> Content-Type: application/x-www-form-urlencoded
>>
>> grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
>> &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>>
>> It will respond with JSON such as:
>>
>> {
>> "access_token":"SlAV32hkKG",
>> "token_type":"Bearer",
>> "expires_in":3600,
>> "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>> "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
>> }
>>
>> id_token is JWT encoded JSON. When you decode it, you will get something
>> like:
>>
>>
>> {
>> "iss": "https://server.example.com",
>> "sub": "alice",
>> "aud": "https://blog.example.com",
>> "exp": 1311281970,
>> "iat": 1311280970
>> }
>>
>> You can put these in the session cookie for easy access from the web
>> application such as blog subsequently. Make sure that you store them in the
>> cookie that was bound for the state parameter value that came back with
>> code.
>>
>> This I think solves your use case, does it not?
>> That's about the bear minimum you have to do to do the authentication...
>>
>
> I finally got some time to read through this, I've looked at OAuth, Bearer
> Token, Basic and Digest Auth documentation. There would appear to be no
> 100% straightforward way for clients and servers to indicate a URL that
> controls that session. I've put this proposal in our wiki page, including
> the proposed text, some background, use cases and implementations. One use
> case is for client side apps to be able determine the user they are dealing
> with and render the page accordingly.
>
> http://www.w3.org/community/rww/wiki/User_Header
>
> Feedback welcome! (And Merry Christmas :))
>
> [[
> Introduction
>
> There would appear to be no simple way in HTTP, to indicate an HTTP URL
> referring to the User that is currently controlling a session. This would
> be useful for both clients and servers, and, in particular to allow client
> side applications to personalize a page. Architecturally, a clean, modular,
> separation of identity and verified identity (authentication) may be
> beneficial.
>
> There has been some discussion on whether the "From" header can be used to
> identify a user in HTTP, but for historical reasons it's limited to email,
> any change to this would likely get some pushback from the IETF.
>
> The suggestion has been to choose another header, and the latest proposal
> is to create a new User header. The text below is very similar to the
> existing "From" header
> Proposed Text User
>
> The User request-header field, if given, SHOULD contain an identifier for
> the human user who controls the requesting user agent. The address SHOULD
> be machine-usable, as defined by the "URI General Syntax" RFC 3986<http://tools.ietf.org/html/rfc3986>
>
> User = "User" ":" URI
>
> An example is:
>
> User: http://www.w3.org/People/Berners-Lee/card#i
>
> This header field MAY be used for logging purposes and as a means for
> identifying the source of invalid or unwanted requests. It SHOULD NOT be
> used as an insecure form of access protection. The interpretation of this
> field is that the request is being performed on behalf of the person given,
> who accepts responsibility for the method performed. In particular, robot
> agents SHOULD include this header so that the person responsible for
> running the robot can be contacted if problems occur on the receiving end.
>
> The client SHOULD NOT send the User header field without the user's
> approval, as it might conflict with the user's privacy interests or their
> site's security policy. It is strongly recommended that the user be able to
> disable, enable, and modify the value of this field at any time prior to a
> request.
>
> Additionally, servers MAY send this header, having verified the identity
> of a user, enabling client side apps to personalize a page.
> Use Cases Page Personalization
>
> The user header would allow a personalization of pages for client side
> apps. One might display a user's name, avatar and homepage, by
> dereferencing the URL and finding out more information.
> Server Response
>
> A server may respond with a user header to tell a client who is in control
> of the current session. The client may use this information to access
> locally stored information.
> Endpoint Discovery
>
> By dereferencing a URL it may be possible to find further endpoints, for
> example, in order to authenticate the idenitity.
> Identity Verification
>
> While the user header is simply a hint, it is possible to imagine a
> scenario where more information is provided, such as a key pair in TLS, or
> additional information such as the "Authorization" header, to enable the
> server to verify the authenticity of the User. For example using Basic Auth
> the user may not contain the ":" character, so this would, enable a URL to
> be associated with a password.
> Implementations
>
> - OpenLink Data Spaces <http://ods.openlinksw.com/wiki/ODS/>
> - rww.io
> - data.fm
>
> ]]
>
>
>
>>
>> [1] See http://en.wikipedia.org/wiki/Bearer_instrument
>>
>>
>>
>> (2013/07/19 18:23), Torsten Lodderstedt wrote:
>>
>>> Hi Melvin,
>>>
>>> <snip>
>>>
>>>>
>>>> 1) You just need a hint? So you don't rely on this data for access
>>>> control. Use any header you want.
>>>> 2) You want to control access to a resource. This requires
>>>> trustworthy/authenticated identity data. Here the obvious way is
>>>> an OAuth access token (authorization header, BEARER scheme). In
>>>> your specific case, it might be required to even specify the
>>>> tokens format. JSON web tokens would be the right choice in my
>>>> opinion.
>>>>
>>>> Why does you concept require the user id to be a URL?
>>>>
>>>>
>>>> Hi Thorsten, the concept does not require a URL, but it needs a header
>>>> that does not *forbid* a URL, and this was the issue with "From". The
>>>> reason is that many people host user profiles on a web URL, so we
>>>> would like to be inclusive of that group of people.
>>>>
>>>> I'm not 100% familiar with all the latest changes to OAuth / OpenID
>>>> Connect, but if there is something in those specifications that could
>>>> be reused to send an identity to a server, and you could point me to
>>>> what to read up on, I'd be grateful.
>>>>
>>>
>>> sure.
>>>
>>> Latest information regarding OAuth can be obtained on the WG page
>>> (https://datatracker.ietf.org/wg/oauth/)
>>>
>>> Sending a token to a protected resource uses the BEARER authorization
>>> scheme (http://tools.ietf.org/html/rfc6750) and works like this:
>>>
>>> GET /resource HTTP/1.1
>>> Host: server.example.com
>>> Authorization: Bearer mF_9.B5f-4.1JqM
>>>
>>> "mF_9.B5f-4.1JqM" is the actual token typically containing identity and
>>> authz data about the user on whos behalf the request is being performed.
>>>
>>> From the client's perspective, this token is opaque and can be utilize
>>> any format the OAuth authorization server and the respective resource
>>> server agreed upon. The WG also specified a certain token format, which
>>> is called JSON Web Token
>>> (http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-10). The
>>> format allows to represent identity data (so-called claims) in a
>>> cryptographically protected way. One of those claims is "sub", an user
>>> account identifier which may also be a URI. A typical JWT contains
>>> claims identifying the IDP (iss), the resource server the token is
>>> targeted at (aud) and the user id (sub).
>>>
>>> This is an example JWT (prior signature processing etc):
>>>
>>> {"iss":"https://idp.mydomain.com",
>>> "aud":"https://resourceserver.otherdomain.org"
>>> "exp":1300819380,
>>> "sub":"http://this.is.the/user/bmeier
>>> <http://this.is.the/user/identifier>"}
>>>
>>> regards,
>>> Torsten.
>>>
>>>
>>>> Regards,
>>>> Torsten.
>>>>
>>>>
>>>>
>>>> Melvin Carvalho <melvincarvalho at gmail.com
>>>> <mailto:melvincarvalho at gmail.com>> schrieb:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 18 July 2013 19:38, Torsten Lodderstedt
>>>> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>>
>>>> wrote:
>>>>
>>>> I fully agree with George und would like to add: why don't
>>>> you just use the authorization header to send identity
>>>> data/credentials/tokens to the server in order to allow
>>>> for access control?
>>>>
>>>>
>>>> Hi Thorsten, thanks for the tip. If there's an existing way to
>>>> identify to a server a user's URL via a header, I'd love to
>>>> learn more about that. It's preferable to reuse existing
>>>> tools, if possible, than to create something new.
>>>>
>>>>
>>>>
>>>>
>>>> George Fletcher <gffletch at aol.com
>>>> <mailto:gffletch at aol.com>> schrieb:
>>>>
>>>>
>>>> I'm a little confused... first the spec says
>>>>
>>>> The current text includes: "It SHOULD NOT be used
>>>> as an insecure form of access protection." -- This
>>>> is the same as the "From" header (which may
>>>> contain an email address). Do you think stronger
>>>> wording is required.
>>>>
>>>> and then you follow that up with
>>>>
>>>> In particular, one thing we are working on in the
>>>> Read Write Web Community Group is fine grained
>>>> access control for writing or appending a file.
>>>> It's helpful to know who is trying to make a
>>>> change before returning e.g. SUCCESS or FORBIDDEN
>>>> response codes.
>>>>
>>>> Since there is no authentication or proof associated
>>>> with the 'User' header, how can you use it for fine
>>>> grained access control? Is the expectation that the
>>>> value is an untrusted identification of the user that
>>>> can be used to optimize certain use cases? If so, I'm
>>>> not sure which use cases it helps?
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 7/18/13 12:49 PM, Melvin Carvalho wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18 July 2013 01:54, John Kemp <john at jkemp.net
>>>>> <mailto:john at jkemp.net>> wrote:
>>>>>
>>>>> The problem, in general, with putting identifiers
>>>>> in HTTP requests is that they get mistaken for
>>>>> being real things. User is no worse (or better)
>>>>> than User-Agent. Remember all of the mess about
>>>>> how websites would attempt to render sites to
>>>>> clients based on the contents of the User-Agent
>>>>> header, and how long it's taken for something
>>>>> better to appear for that task?
>>>>>
>>>>>
>>>>> Yes, I agree that User-Agent can be slightly
>>>>> problematic. Some spiders such as googlebot actually
>>>>> put their URL in the User-Agent header, as a
>>>>> semi-colon separated list, which is not ideal. The
>>>>> user and the user-agent are different concepts. The
>>>>> proposed header would be a simpler solution, imho.
>>>>>
>>>>>
>>>>> 'Just a hint' doesn't tell anyone what this is
>>>>> really going to be used for. Are there use-cases
>>>>> written down, in addition to a syntax?
>>>>>
>>>>>
>>>>> The current text includes: "It SHOULD NOT be used as
>>>>> an insecure form of access protection." -- This is
>>>>> the same as the "From" header (which may contain an
>>>>> email address). Do you think stronger wording is
>>>>> required.
>>>>>
>>>>> The use case is the same as "From" in fact, my ideal
>>>>> would have been just to loosen the scope of "From"
>>>>> but there was pushback from the IETF on this, with
>>>>> the suggestion to think of another header name.
>>>>>
>>>>> In particular, one thing we are working on in the
>>>>> Read Write Web Community Group is fine grained access
>>>>> control for writing or appending a file. It's
>>>>> helpful to know who is trying to make a change before
>>>>> returning e.g. SUCCESS or FORBIDDEN response codes.
>>>>>
>>>>>
>>>>> On a more specific level, this looks like
>>>>> "On-behalf-of" - a more indicative name than
>>>>> "user" for the seemingly potential usage (this
>>>>> request is performed on behalf of the user X)?
>>>>>
>>>>>
>>>>> I'd be very happy to reuse something existing, so
>>>>> long as it allowed URLs and email address too. If
>>>>> I'm correct, On-behalf-of is email specific?
>>>>>
>>>>>
>>>>> I'm not sure why OpenIDs couldn't appear in this
>>>>> header, FWIW. The recipient could run OpenID
>>>>> protocol with the client, regarding the
>>>>> identifier sent in the header. That would allow
>>>>> "verification" of the OpenID to occur, wouldn't it?
>>>>>
>>>>>
>>>>> Well I hadnt thought of that, but yes that could work
>>>>> quite well! One of the perceived issues with OpenID
>>>>> as a URL (dating back as far as Yadis) was that the
>>>>> UX for typing in an HTTP URL lead to a loss of
>>>>> conversions. If this could be done by the software
>>>>> and may save some typing, especially on mobile
>>>>> devices. The same technique could be used with PKI if
>>>>> the URL contained a public key and the (rich) client
>>>>> could store the private key. I think that will
>>>>> become a more valuable use case next year when crypto
>>>>> on the browser becomes a REC
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>> On Jul 17, 2013, at 7:41 PM, Melvin Carvalho
>>>>> <melvincarvalho at gmail.com
>>>>> <mailto:melvincarvalho at gmail.com>> wrote:
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> > On 18 July 2013 01:06, Nat Sakimura
>>>>> <sakimura at gmail.com <mailto:sakimura at gmail.com>>
>>>>>
>>>>> wrote:
>>>>> > Hi.
>>>>> >
>>>>> > I am forwarding the mail in the identity
>>>>> commons list.
>>>>> >
>>>>> > Apparently, there is an initiative at W3C
>>>>> proposing a new "identity" header, which I
>>>>> believe is actually harmful for the general
>>>>> public. Simple web sites are going to take it as
>>>>> authenticated identity and thus will cause
>>>>> identity theft of their users.
>>>>> >
>>>>> > Their proposal is to include
>>>>> >
>>>>> > User: http://this.is.the/user/identifier
>>>>> >
>>>>> > in the HTTP header.
>>>>> >
>>>>> > Could those of you active in W3C reach out to
>>>>> them?
>>>>> >
>>>>> > As I have written below, if it were to just
>>>>> include the IdP address as a hint, I am kind of
>>>>> fine.
>>>>> >
>>>>> > Thanks for sharing this. Since this was my
>>>>> proposal, I hope I can shed a bit of light light.
>>>>> >
>>>>> > Firstly, it's not the W3C, simply a group of
>>>>> people brainstorming in the a W3C hosted forum
>>>>> (aka community groups). The proposal has no
>>>>> official standing, but if there are no
>>>>> objections, the idea is to try and push the idea
>>>>> upstream.
>>>>> >
>>>>> > Yes, the idea is that it is just a hint. Note
>>>>> the text:
>>>>> >
>>>>> > "The client SHOULD NOT send the User header
>>>>> field without the user's approval, as it might
>>>>> conflict with the user's privacy interests or
>>>>> their site's security policy. It is strongly
>>>>> recommended that the user be able to disable,
>>>>> enable, and modify the value of this field at any
>>>>> time prior to a request."
>>>>> >
>>>>> > We asked the IETF if we could use the "From"
>>>>> header for this, but the feedback is that "From"
>>>>> is restricted to email, and this would be
>>>>> difficult to change. The suggestion was to come
>>>>> up with a new header. Very happy to have
>>>>> feedback, I've followed IIW work for many years.
>>>>> >
>>>>> >
>>>>> > Best,
>>>>> >
>>>>> > Nat
>>>>> >
>>>>> > ---------- Forwarded message ----------
>>>>> > From: Kaliya "Identity Woman"
>>>>> <kaliya-lists at identitywoman.net
>>>>> <mailto:kaliya-lists at identitywoman.net>>
>>>>> > Date: 2013/7/18
>>>>> > Subject: Re: [community] from W3C….Fwd:
>>>>> Proposal: "User" header field
>>>>> > To: Nat Sakimura <sakimura at gmail.com
>>>>> <mailto:sakimura at gmail.com>>
>>>>> > Cc: "community at lists.idcommons.net
>>>>> <mailto:community at lists.idcommons.net>"
>>>>> <community at lists.idcommons.net
>>>>> <mailto:community at lists.idcommons.net>>
>>>>>
>>>>> >
>>>>> >
>>>>> > Yes Nat, Thats sort of what I got from reading
>>>>> it.
>>>>> >
>>>>> > Who among us is very active in the W3C world?
>>>>> >
>>>>> > If no one should we be figuring out who should
>>>>> be?
>>>>> >
>>>>> > Should we write them a letter asking them to
>>>>> send "identitish" proposals to IIW? or other
>>>>> forums for good input?
>>>>> >
>>>>> > Maybe we should write something that is like
>>>>> understanding identity basics for technical
>>>>> specification folks across a range of standards
>>>>> bodies?
>>>>> >
>>>>> > - Kaliya
>>>>> >
>>>>> > On Jul 17, 2013, at 3:32 AM, Nat Sakimura wrote:
>>>>> >
>>>>> >> Whoa, what's that?!
>>>>> >>
>>>>> >> That's not only useless but actually harmful.
>>>>> >>
>>>>> >> I can kind of see some utility in sending the
>>>>> IdP address, but not the user.
>>>>> >>
>>>>> >> =nat via iPhone
>>>>> >>
>>>>> >> On Jul 16, 2013, at 7:39, "Kaliya \"Identity
>>>>> Woman\"" <kaliya-lists at identitywoman.net
>>>>> <mailto:kaliya-lists at identitywoman.net>> wrote:
>>>>> >>
>>>>> >>> Hi folks,
>>>>> >>> Apparently the W3C wants to send "user"
>>>>> names along in HTTP headers.
>>>>> >>> I thought some folks who know about identity
>>>>> and how it does/could/should work might be up for
>>>>> chiming in over there.
>>>>> >>> It seems like Authentication of identity
>>>>> might be a good thing rather then just assertion.
>>>>> >>> - Kaliya
>>>>> >>>
>>>>> >>>
>>>>> >>> Begin forwarded message:
>>>>> >>>
>>>>> >>>> From: Christine
>>>>> >>>
>>>>> >>>> As you know, I'm a big proponent of open
>>>>> standards. For this reason I monitor many groups.
>>>>> You might be interested in the W3C Read Write Web
>>>>> community group: http://www.w3.org/community/rww/
>>>>> >>>>
>>>>> >>>> I sent you a message a few weeks ago about
>>>>> Tabulator.
>>>>> >>>>
>>>>> >>>> See below messages about User header field.
>>>>> If you are not already a member, I recommend you
>>>>> join and contribute!
>>>>> >>>>
>>>>> >>>> Christine
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> -------- Original Message --------
>>>>> >>>> Subject: Re: Proposal: "User" header field
>>>>> >>>> Resent-Date: Sat, 13 Jul 2013 16:19:02
>>>>> +0000
>>>>> >>>> Resent-From: public-rww at w3.org
>>>>> <mailto:public-rww at w3.org>
>>>>> >>>> Date: Sat, 13 Jul 2013 12:08:37 -0400
>>>>> >>>> From: Joe <presbrey at gmail.com
>>>>> <mailto:presbrey at gmail.com>>
>>>>> >>>> To: Melvin Carvalho
>>>>> <melvincarvalho at gmail.com
>>>>> <mailto:melvincarvalho at gmail.com>>
>>>>> >>>> CC: public-rww <public-rww at w3.org
>>>>> <mailto:public-rww at w3.org>>
>>>>>
>>>>> >>>>
>>>>> >>>> Great job Melvin!
>>>>> >>>>
>>>>> >>>> Data.fm sends the User header already :)
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On Jul 13, 2013, at 10:55 AM, Melvin
>>>>> Carvalho <melvincarvalho at gmail.com
>>>>> <mailto:melvincarvalho at gmail.com>> wrote:
>>>>> >>>>
>>>>> >>>>> I would be nice to be able to identify a
>>>>> user in HTTP, especially with read/write
>>>>> protocols and access control, it can be important
>>>>> to know who is trying to change something.
>>>>> >>>>>
>>>>> >>>>> There has been some discussion on whether
>>>>> the "From" header can be used to identify a user
>>>>> in HTTP, and my from most people is that this
>>>>> would be a good candidate to send a user, but for
>>>>> historical reasons it's limited to email, and
>>>>> changing this would perhaps get some pushback
>>>>> from the IETF.
>>>>> >>>>>
>>>>> >>>>> The suggestion has been to choose another
>>>>> header, so I thought that "User" might be a good
>>>>> candidate, since we have User Agent arleady.
>>>>> >>>>>
>>>>> >>>>> Here's the proposed text:
>>>>> >>>>>
>>>>> >>>>> [[
>>>>> >>>>> User
>>>>> >>>>>
>>>>> >>>>> The User request-header field, if given,
>>>>> SHOULD contain an identifier for the human user
>>>>> who controls the requesting user agent. The
>>>>> address SHOULD be machine-usable, as defined by
>>>>> the "URI General Syntax" RFC 3986
>>>>> >>>>> User = "User" ":" URI
>>>>> >>>>>
>>>>> >>>>> An example is:
>>>>> >>>>>
>>>>> >>>>> User:
>>>>> http://www.w3.org/People/Berners-Lee/card#i
>>>>> >>>>> This header field MAY be used for logging
>>>>> purposes and as a means for identifying the
>>>>> source of invalid or unwanted requests. It SHOULD
>>>>> NOT be used as an insecure form of access
>>>>> protection. The interpretation of this field is
>>>>> that the request is being performed on behalf of
>>>>> the person given, who accepts responsibility for
>>>>> the method performed. In particular, robot agents
>>>>> SHOULD include this header so that the person
>>>>> responsible for running the robot can be
>>>>> contacted if problems occur on the receiving end.
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> The client SHOULD NOT send the User header
>>>>> field without the user's approval, as it might
>>>>> conflict with the user's privacy interests or
>>>>> their site's security policy. It is strongly
>>>>> recommended that the user be able to disable,
>>>>> enable, and modify the value of this field at any
>>>>> time prior to a request.
>>>>> >>>>>
>>>>> >>>>> ]]
>>>>> >>>>>
>>>>> >>>>> Feedback welcome!
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> ______________________________
>>>>> ______________________________
>>>>> >>> You received this message as a subscriber on
>>>>> the list:
>>>>> >>> community at lists.idcommons.net
>>>>> <mailto:community at lists.idcommons.net>
>>>>>
>>>>> >>> To be removed from the list, send any message
>>>>> to:
>>>>> >>> community-unsubscribe at lists.idcommons.net
>>>>> <mailto:community-unsubscribe at lists.idcommons.net>
>>>>>
>>>>> >>>
>>>>> >>> For all list information and functions, see:
>>>>> >>> http://lists.idcommons.net/
>>>>> lists/info/community
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Nat Sakimura (=nat)
>>>>> > Chairman, OpenID Foundation
>>>>> > http://nat.sakimura.org/
>>>>> > @_nat_en
>>>>> >
>>>>> > _______________________________________________
>>>>> > specs mailing list
>>>>> > specs at lists.openid.net
>>>>> <mailto:specs at lists.openid.net>
>>>>>
>>>>> >
>>>>> http://lists.openid.net/
>>>>> mailman/listinfo/openid-specs
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > specs mailing list
>>>>> > specs at lists.openid.net
>>>>> <mailto:specs at lists.openid.net>
>>>>>
>>>>> >
>>>>> http://lists.openid.net/
>>>>> mailman/listinfo/openid-specs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> specs mailing list
>>>>> specs at lists.openid.net <mailto:specs at lists.openid.net
>>>>> >
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>>
>>>>
>>>> --
>>>> George Fletcher <http://connect.me/gffletch>
>>>>
>>>> ------------------------------
>>>> ------------------------------------------
>>>>
>>>> specs mailing list
>>>> specs at lists.openid.net <mailto:specs at lists.openid.net>
>>>>
>>>>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>> --
>> Nat Sakimura (n-sakimura at nri.co.jp)
>> Nomura Research Institute, Ltd.
>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>>
>> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 することを意図しております。意図された受取人以外の方によるこれらの情報の
>> 開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
>> 信されたメールを削除していただきますようお願い致します。
>> PLEASE READ:
>> The information contained in this e-mail is confidential and intended for
>> the named recipient(s) only.
>> If you are not an intended recipient of this e-mail, you are hereby
>> notified that any review, dissemination, distribution or duplication of
>> this message is strictly prohibited. If you have received this message in
>> error, please notify the sender immediately and delete your copy from your
>> system.
>>
>>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20131225/dba10fd8/attachment-0001.html>
More information about the specs
mailing list