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
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