hdknr’s posterous

7.5.14 Private Personal Identifier

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

Type:  xs:base64binary

Definition:  A private personal identifier (PPID) that identifies the Subject to a Relying Party. The word “private” is used in the sense that the Subject identifier is specific to a given Relying Party and hence private to that Relying Party. A Subject’s PPID at one Relying Party cannot be correlated with the Subject’s PPID at another Relying Party. Typically, the PPID SHOULD be generated by an Identity Provider as a pair-wise pseudonym for a Subject for a given Relying Party. For a self-issued Information Card, the Self-issued Identity Provider in an Identity Selector system SHOULD generate a PPID for each Relying Party as a function of the card identifier and the Relying Party’s identity. The processing rules and encoding of the PPID claim value is specified in Section 7.6.

Compatibility Note:  Some existing Identity Selectors omit listing the PPID claim as an ic:SupportedClaimType from the ic:SupportedClaimTypeList when saving a self-issued Information Card in the Information Cards Transfer Format defined in Section 6.1, even though the PPID claim is supported by the card.  This behavior is deprecated, as all supported claims SHOULD be listed.  Nonetheless, Identity Selectors MAY choose to recognize this case and support the PPID claim for self-issued cards not explicitly listing this claim.

PPIDはRPに対するSubjectの識別子。「プライベート」はSubject識別子があるRPに専用のもので、つまりRPに対してプライベートということ。あるRPでのSubjectのPPIDは他のRPでのSubjectのPPIDと関連性を持ってはいけない。たいていはPPIDは与えられたRPに対するサブジェクトの”pair-wise pseumonym"としてのIdentity Providerによって生成されるべき。自己発行情報のCardではIdentity　Selectorシステムの自己発行Identity　ProviderがそれぞれのRPのPPIDをカード識別子とRPのアイデンティティの関数として生成すべき。PPIDのクレーム値の処理ルールとエンコーディングは7.6章。

（そのうち訳を見直すよ）

Definitions for a Common Identity Framework

Posted on Tuesday 9 June 2009

The Proposal for a Common Identity Framework begins by explaining the termnology it uses.  This wasn’t intended to open up old wounds or provoke ontological debate.  We just wanted to reduce ambiguity about what we actually mean to say in the rest of the paper.  To do this, we did think very carefully about what we were going to call things, and tried to be very precise about our use of terms.

Claim:  an assertion made by one subject about itself or another subject that a relying party considers to be “in doubt” until it passes “Claims Approval”

Claims Approval: The process of evaluating a set of claims associated with a security presentation to produce claims trusted in a specific environment so it can used for automated decision making and/or mapped to an application specific identifier.

Claims Selector:  A software component that gives the user control over the production and release of sets of claims issued by claims providers. 

Security Token:  A set of claims.

要求：自分自身に関するサブジェクト、あるいは要求承認を通るまで疑わしいRPが考える他のサブジェクトによって作られたアサーション。

要求承認：セキュリティ表現に関連付けられた要求セットを強化するプロセスであり、特定の環境において信頼できる要求を生成するので、自動的意思決定に使われたりアプリケーションごとの識別子にマップされる。

要求セレクタ：ユーザーが要求プロバイダによって発行された要求セットを生成したり開放したりすることができるようにするソフトウェアコンポーネント。

セキュリティトークン：　要求セット。

Summary

So, to summarize:

1. OAuth and CX is almost identical in the protocol flow.
2. OAuth requires manual step to establish the Consumer’s identifier called Consumer Key, while CX leverages on metadata including its identifier in XRD.
3. OAuth does not require an identity framework such as OpenID while CX does.
4. OAuth uses Token Secrets. In CX, there is no need of them.
5. CX leverages on public key cryptography for security while OAuth depends on shared secret. In another words, in CX, there is no shared secret.
6. Authorized Request Token (cx:ContractID) and Access Token (cx:Contract) is generated at different point in the sequence in OAuth, while it is generated simultaneously in CX.
7. OAuth implicitly assumes that the User at the Consumer and the Service is the same guy and binds a local user at the Consumer to another local user at the Service Provider by Request Token, while CX does not and leverages on the User’s global Identifier to distinguish them.
8. OAuth implicitly assumes that the User in the different point in the sequence is the same guy, while CX does not and leverages on the User’s global Identifier to distinguish them.
9. In CX, the authorization fails if the identifier in the cx:Offer/cx:Contract does not match with the User’s Identifier
10. CX is not vulnerable to the OAuth Fixation Attack, though on the surface, the protocol flow seems almost identical.