Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] AW: How should selectors advertise themselves?

Nennker, Axel wrote on 01/04/2008 06:01:35 AM:

<snip/>

> > I see problems with the capabilities because it is unclear
> > who defines the interop standards and who decides whether a
> > selctor is allowed to claim interoperability.

I think these problems are orthogonal to whether we advertise "capability"
vs. "product". If a browser advertises a capability, but does not support
it, it (browser) will not work. A product based advertisement requires
Relying Party's to somehow discover/track which browsers support which
features, and if they guess wrong the browser won't work. How is that
better?

> > The openinfocard selector for example does not support
> > symmetric binding and does not support issuerPolicy.

Let me take these separately:
a) "symmetric binding" is in the contract between the Selector and the IdP
and is expressed in the Metadata of the IdP. Nothing the RP does impacts
this. If your selector doesn't want to support this it can reject import of
cards that require it.
b) issuerPolicy implies a scenario where the RP "owns" the STS. This one is
tricky, on the one hand, conceptually it semes no different from asking for
a token from an Issuer for which you have no cards. On the other hand it
does require a new message exchange pattern in the selector. Support for
this is a capability of the selector, right?

> > Therefore I would not sent the rpInterop part of the http
> > header but the name and selectorVersion parts only.
> > But other selectors might claim interoperability while they are not.

<ContentPreviouslySentOffList>

I guess before deciding on a solution, we should decide on some important
requirements. Some of mine would be:
      1) Relying Party sites should be able to detect capabilities of
Client/Selector in order to formulate appropriate markup.>
      2) A new Client/Selector should be able to be supported without
changes to existing Relying Party sites.
      3) A new capability added to a Client/Selector should be able to be
ignored by Relying Party sites that do not yet support it.

Therefore, I believe that its better for a Relying Party site to know the
capabilities of a Client/Selector than to know the "brand"/product/version.
In the CardSpace 1.0 world, there are three main capabilities related to
content provided to browsers/selectors:
      a) OBJECT tag for Type-application/x-informationCard,
      b) INFORMATIONCARD/ADD behavior,
      c) Scriptable invocation of the Helper object.
Additionally, there may be a dependency on support for:
      d) Relying Party/STS
      e) Identity Provider/STS

So I would prefer something like HTTP headers with:
      x-Accept-Identity-Markup: Object-x-informationCard;
InformationCard-Behavior; Scriptable-Helper
      x-Accept-Identity-Service: IdP; RP

</ContentPreviouslySentOffList>;


> >
> > have fun
> > Axel
> >
> > ps.: Why are you sending this only to higgins-dev but not to
> > the google group?

By sending messages to this list we agree to Eclipse terms wrt content of
our messages. It is unclear what terms are implied by messages sent
received on a google list.

<snip/>



Back to the top