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

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

I would hate to have to have folks keep up with all the brands and versions, and I'm not sure the brand and version would do anything for interop

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

"Paul Trevithick" ---01/04/2008 12:10:20 PM---We should include both capabilities-based values and brand&version-based

From:	"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
To:	"'Higgins \(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
Cc:	Michael.Jones@xxxxxxxxxxxxx
Date:	01/04/2008 12:10 PM
Subject:	RE: [higgins-dev] AW: How should selectors advertise themselves?

---

We should include both capabilities-based values and brand&version-based
values. The former appeals to the optimist in me. The latter to the
pragmatist. 

> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Nennker, Axel
> Sent: Friday, January 04, 2008 12:44 PM
> To: higgins-dev@xxxxxxxxxxx
> Cc: Michael.Jones@xxxxxxxxxxxxx
> Subject: AW: [higgins-dev] AW: How should selectors advertise themselves?
> 
> 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
> >
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev