Technical Insights

This is work in progress. No guarantee that any of this is correct; if you know something on this page is incorrect, please correct; if you aren't absolutely sure, please comment on this page's [[Talk::Technical_Insights|Talk]] page. If you think you have an answer for an open question, please do add.

Summary of the InfoCard invocation

1. HTTP GET of a web page.
2. Site returns a page with InfoCard tags.
3. InfoCard identity selector invoked.
4. User selects a card.
5. Identity selector somehow gets a token
6. Identity selector returns token to browser
7. Browser returns token to site.

Does communication between the identity selector and a token server use only the WS-protocols?

Or are callable interfaces also specified?

What about the self-issued token server?

Is there an InfoCard-specific token?

The InfoCard documentation mentions security token types, including X.509, Kerberos and SAML. Tokens may also be self-issued. The format for the signature of a self issued token is the XML-DSig of a canonicalized token (W3 xml-exec-c14n). Is there anything else?

Does 'self-issued token' mean SAML token?

Section 6.5. Using Self-issued Token of A Technical Reference for InfoCard ... http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf

What are the exact versions of the WS-* specifications supported by InfoCard when released?

One or more of the links on the Microsoft InfoCard web pages appear to be to earlier versions of WS specifications, not to versions approved by OASIS.

Do all communications between an identity selector and other software (except browser) use SOAP?

Are there exceptions?

How are claim types identified?

Identifiers of claim types may be of the form:

1. http://schemas.microsoft.com/ws/2005/05/identity/claims/<claimTypeName>
2. urn:schemas-microsoft-com:ws:2005:05:identity:claims:<claimTypeName>

What's the difference?

Where is the authoritative reference of claim types?

Is it at http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf

Is there a machine-processable schema somewhere?

What is the InfoCard output format?

So far, it seems to be undocumented? Is that intentional? Example:

<EncryptedStore xmlns="http://schemas.microsoft.com/ws/2005/05/identity">
    <StoreSalt>/rVu7KqhwJPHcLS1sgtPTw==</StoreSalt> 
    <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
        <enc:CipherData>
            <enc:CipherValue>XAmcxM2hih...rPQ==</enc:CipherValue> 
        </enc:CipherData>
    </enc:EncryptedData>
</EncryptedStore>

Where and when will the various extensions to specifications be submitted to which standards body?

Is there a commitment to abide by whatever standard the body comes up with? This question is intended to include, tor example, the InfoCard schema specification, the identity extension to ws-addressing, ... . (Please extend the list.)

Will there be a more complete definition of the Policy declaration for web browsers?

At the moment, it is a very limited subset of the possible RP policy.

What's the proper way for a client to invoke the InfoCard UI given a web browser policy declaration?

E.g. how do we immediately enable the Windows version of Firefox with the Microsoft InfoCard selector.

How did Microsoft implement InfoCard? Managed code? C#? ...?

Answered by Arun Nanda, Microsoft:

It's a combination of managed and native code. The decision to use managed code (where it's used) is more "engineering efficiency" motivated than any technical reasons. Since we make use of the WS protocol stack as provided by Indigo from within the Infocard system, and Indigo is implemented in managed code, it made sense to implement the Infocard in managed code as well. The Identity Selector UI pieces are implemened in native code to make use of native win32 facilities and have the UI hosted within the user's shell.

Did you construct InfoCard as a set of interacting components? If so, which?

Answered by Arun Nanda, Microsoft:

Infocard is a set of interacting components factored at suitable boundaries. For example, at a coarse level, there is the Identity Selector which essentially includes a protocol module (to interact with STS'es to obtain tokens) and the UI module (with the security characteristics of protected desktop). Then there is the Card Store, which plugs in underneath the Identity Selector, which securely stores a user's card collection and the Ledger that tracks a user's usage of cards at various sites/services. Then there is the Self-Issued Identity STS that acts as the identity provider for self-issued cards. These are system level components which are collectively exposed to an application at the platform level. In other words, an app that relies on Infocards is not aware of the seams between the interacting components that make up the Infocard system.

Further questions on this topic by Joaquin Miller, NetMesh:

Are the following correct?

The interface exposed to an application does not include access to the Ledger.

The interface exposed to an application for access to the Card Store is the configure operation. When that operation is invoked, one of the system level components takes over and presents a user interface to the user. An application has no access to the Card Store.

OSIS Main Page