AW: [higgins-dev] AW: How should selectors advertise themselves?

["Nennker, Axel" <Axel.Nennker@xxxxxxxxxxxxx>]

Thanks for suggesting capability indicating headers though I still think that these are difficult to agree on. My experience is that these kind of protocols end in negotiating capabilties of both sides and that "vendors" tend to invent their own values...

But, anyways. I hope that there will be more comments regarding the capability headers.

-Axel

ps.: The STS owned by RP stuff is not very well understood. At least not by me ;-)
There was recently a post in the CardSpace team blog regarding this, but its lenght alone is an indication of the complexity of the matter. I remember that Mike Jones told me about the fact that RP and STS could have a shared symmetric key which is specified in the RP's policy. This would be a capability that the openinfocard selector would (probably) not be able to handle. We have some code regarding this but was never tested. The capability headers might get very complex.

> -----Ursprüngliche Nachricht-----
> Von: higgins-dev-bounces@xxxxxxxxxxx 
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] Im Auftrag von 
> Michael McIntosh
> Gesendet: Freitag, 4. Januar 2008 16:50
> An: Higgins (Trust Framework) Project developer discussions
> Cc: higgins-dev@xxxxxxxxxxx; higgins-dev-bounces@xxxxxxxxxxx
> Betreff: 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/>
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>