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