| Re: [higgins-dev] AW: How should selectors advertise themselves? |
|
Mike,
You mention a scriptable helper object. As browser helper object are many and varied, I assume you are talking about one that deals with information cards and security tokens at some level. To simply say that we have a scriptable helper object may not be enough - we may need to also specify its capabilities with respect to tokens and information cards in a little more detail. Although I have read of several that deal with information cards and tokens, I would like to know precisely which one you mean. Is it one supplied by Microsoft for IE7? Is it cross-browser/cross platform? What capabilities are you assuming this helper object provides?
Thanks,
Daniel
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 1/4/2008 8:49 AM >>> 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 |