[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[higgins-dev] AW: How should selectors advertise themselves?
|
resending this to the list because I had to subscribe first.
-Axel
> -----Ursprüngliche Nachricht-----
> Von: Nennker, Axel
> Gesendet: Freitag, 4. Januar 2008 11:56
> An: 'Paul Trevithick'; 'Higgins (Trust Framework) Project
> developer discussions'
> Cc: Charles Andres; 'Mike Jones'; 'Pamela Dingle'
> Betreff: AW: How should selectors advertise themselves?
>
> Hi Paul,
> thanks for your suggestions.
> Maybe we could merge the capability-based notion with the
> selector-version notion by making them optional?
>
> ID-Selector: ver='urn:osis:selector:2008-4' ;
> rpInterop='urn:osis:selector-capabilities:S2RP-CS3.5' ;
> name='urn:osis:selector:names:openinfocard' ;
> selectorVersion='0.9.9.20080104'
>
> Allowed values for name, rpInterop, ver and selectorVersion would be:
> ver: 'urn:osis:selector:2008-4'
> rpInterop: 'urn:osis:selector-capabilities:S2RP-CS3.5' or
> 'urn:osis:selector-capabilities:S2RP-CS3.0'
> selectorVersion: Any ASCII-character sequence without "'"
> inside the "'". maxlenth=64 bytes
> name:
> - 'urn:osis:selector:names:higgins'
> - 'urn:osis:selector:names:openinfocard'
> - 'urn:osis:selector:names:CardSpace'
> - 'urn:osis:selector:names:DigitalMe'
>
> 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.
> The openinfocard selector for example does not support
> symmetric binding and does not support issuerPolicy.
> 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.
>
> have fun
> Axel
>
> ps.: Why are you sending this only to higgins-dev but not to
> the google group?
>
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Paul Trevithick [mailto:paul@xxxxxxxxxxxxxxxxx]
> > Gesendet: Freitag, 4. Januar 2008 00:56
> > An: 'Higgins (Trust Framework) Project developer discussions'
> > Cc: Charles Andres; Nennker, Axel
> > Betreff: How should selectors advertise themselves?
> >
> > There is going to be an OSIS con call next Thurs 11AM Eastern
> > (Dial-in:
> > 1-309-946-5000 / 694034#) to discuss how a Selector should
> advertise
> > itself.
> >
> >
> > HBX for Firefox currently adds the header "higgins" with the value
> > "Enabled"
> > but that was just a hack.
> >
> > Ideally we'd have a capabilities-based header. It would indicate
> > compatibility with a specific "Selector-to-RP Interop Spec". At
> > present the only examples of such a spec are Microsoft's documents
> > describing the CardSpace.net3.0-to-RP and the
> CardSpace.net3.5-to-RP
> > interactions. Lacking any accepted name for these specs, I'll call
> > them here S2RP-CS3.0 and
> > S2RP-CS3.5 respectively. Thus we could add a header like this:
> >
> > ID-Selector: ver='urn:osis:selector:2008-4' ;
> > name=''urn:osis:selector-capabilities:S2RP-CS3.5'
> >
> > I expect to see other Selector-to-RP Interop Specs so
> "S2RP-CS3.0" and
> > "S2RP-CS3.5" won't be the only values of XXXXX in
> "S2RP-XXXXX". They
> > might come from a standards body taking over Microsoft's
> specs. They
> > might come from the work of other groups.
> >
> > The advantages of a capabilities-based approach to relying apps and
> > sites are obvious and compelling. The problem is of course getting
> > folks to agree on definitions. It is particularly hard when
> the spex
> > are informally defined and have no name.
> >
> > But if we can't agree on a capabilities-based approach then
> we might
> > decide to include a version number with the "brand"
> > of selector:
> >
> > ID-Selector: ver='urn:osis:selector:2008-4' ;
> > name='urn:osis:selector:names:openinfocard2.8'
> >
> > Or in another field.
> >
> > Other thoughts from the Higgins crew?
> >
> > -Paul
> >
> > -----Original Message-----
> > From: user-centric-identity-interop@xxxxxxxxxxxxxxxx
> > [mailto:user-centric-identity-interop@xxxxxxxxxxxxxxxx] On
> Behalf Of
> > Axel Nennker
> > Sent: Thursday, January 03, 2008 3:57 PM
> > To: User-Centric Identity Interop
> > Subject: Re: Meeting: Consensus on browser-based Identity Selector
> > Presence Indication Methods
> >
> >
> > Have I overlooked arguments from people other than Mike Jones and
> > myself regarding the id-selector advertising discussion?
> > I would like to hear/see arguments/opinions from the other
> > (browser- based or not) id selector groups before the telco starts.
> > http://groups.google.de/group/user-centric-identity-interop/br
> > owse_thread/th
> > read/8d924402ed07e1b1
> > http://ignisvulpis.blogspot.com/2007/12/id-selector-advertising.html
> >
> http://ignisvulpis.blogspot.com/2007/12/http-header-x-id-selector.html
> > http://groups.google.de/group/user-centric-identity-interop/br
> > owse_thread/th
> > read/4495eaffe6690ad0
> >
> > I kind of like the SAML ECP http header:
> > PAOS: ver='urn:liberty:paos:2003-08' ; 'urn:oasis:names:tc:SAML:
> > 2.0:profiles:SSO:ecp'
> > Maybe we could agree on something similar?!
> >
> > ID-Selector: ver='urn:osis:infocard:2008-04' ;
> > name='urn:osis:infocard:names:openinfocard'
> >
> > "ver" is the date when we agree on this.
> > "name" is the name of the selector.
> >
> > have fun
> > Axel
> >
> >
> >
