Skip to main content

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

 

My current favorite value for the id selector advertising HTTP header "X-ID-Selector":

version='urn:osis:infocard:2008-04'; name='urn:osis:infocard:names:openinfocard'; capabilities='+nossl+_javascript_-issuerpolicy'
  • version has a constant value until we change the spec for this HTTP header
  • name is one from a OSIS defined list
  • capabilities is a string of capabilities.
    • "+" indicated support for a capability.
    • "-" indicates missing support for a capability
 


Von: Jim Sermersheim [mailto:jimse@xxxxxxxxxx]
Gesendet: Freitag, 4. Januar 2008 19:27
An: 'Higgins (Trust Framework) Project developer discussions'
Cc: Michael.Jones@xxxxxxxxxxxxx
Betreff: RE: [higgins-dev] AW: How should selectors advertisethemselves?

The use of capabilities-based values resonates strongly with me.  If a brand and version are advertised, I argue that the specification for that states that these values may only be used for purposes of debugging, identifying defects, and discovering the vendor so that problems may be communicated.  It should also state that these values must not be used to discover capabilities.


As long as the capability data uses a nomenclature that produces unique values, and values may be ignored when unknown, then I don't think agreement on values will be a problem.  IANA or some other authority could be used to register well-known or standardized capability values with pointers to the capability's definition.  Vendor-specific or experimental capabilities can be documented elsewhere.  This is a common working pattern for a number of different protocols/services


Jim

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 01/04/08 11:10 AM >>>
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


Back to the top