OSIS Selector Capability Advertisment

The information card community has identified a need for a method where a selector (or selector-selector) can communicate capabilities prior to any transaction taking place. Discussions around the method by which selector data is advertised, the format used to advertise selector data, and the construction and content of the data itself will be summarized here.

Format 1
Proposed by: A. Nennker

version='urn:osis:infocard:2008-04'; name='urn:osis:infocard:names:openinfocard'; capabilities='+nossl+javascript-issuerpolicy'

OSIS Meeting Notes
When adding new meeting notes, please place the newest notes at the top of this section

Meeting: 10 January 2008 (posted by M. Jones)
Thanks Pam. Here's a few additions and refinements from my notes.

We agreed that advertizing capabilities is better than advertizing software versions. We agreed that a new http header should be used for capabilities, and that, if optionally present, any software version information should not be in this header, but instead be in the userAgent string.

A desire was expressed that these capabilities should be discoverable on the client side as well.

While URNs were discussed, ultimately a consensus emerged that the HTTP header already provides sufficient scoping information, and so simple strings would do (and would be more bandwidth efficient).

While pluses and minuses were discussed, ultimately we decided to drop pluses because naming a capability without a "-" prefix would be equivalent to naming it with a "+" prefix.

To make this concrete, I believe that we agreed that these header values would be used to represent the capabilities of the software versions following them:

X-IdentitySelector: ISIPv1.0                           Windows CardSpace in .NET 3.0 X-IdentitySelector: ISIPv1.0 noSSL                     Windows CardSpace in .NET 3.5 X-IdentitySelector: ISIPv1.0 -issuerPolicy     openinfocard

Descriptions of other selectors are left as an exercise to the reader. ;-)

-- Mike

- Hide quoted text - - Show quoted text -

Meeting: 10 January 2008 (posted by P. Dingle)
Identity Selector Capability Advertisement Meeting Date: 10 January, 2008

Attendees:
 * Dale Olds
 * Ben Laurie
 * Tom Carroll
 * Paul Trevithick
 * Tony Nadalin
 * Mike Jones
 * Andy Hodgkinson
 * Daniel Sanders
 * Drummond Reed
 * Mary Ruddy
 * Duane Buss
 * Axel Nennker
 * Pamela Dingle (taking notes, please let me know if anyone sees errors or omissions)

Item 1: IPR It was asked on the call, whether anyone was of the opinion that we were creating any IPR by defining strings for advertising ID Selector capabilities: nobody answered that they were concerned - on that basis the group chose to proceed.

Item 2: String Format Several proposals have been made as to the format of the actual string
 * Tony noted that it may not be possible to know what the correct format is until we know what the string will actually communicate
 * Both capabilities and software version information may be in the string
 * The group agreed that capabilities are preferable
 * The group also agreed that versions may be published but should NEVER be relied on
 * Nobody wants to go down the path of lying about software brand or version in advertisements, we've seen where that can go with browser user agent strings.

Item 3: Protocol/Advertisement Mechanism new, distinct HTTP header Headers available to Relying Parties -- nobody knew of any issues, there are definitely no issues with Apache, people also thought that IIS was also fine. HTTP only addresses browser based scenarios advertisement the string semantics from the advertisement mechanism, and work on the semantics first.
 * Some discussion went on around use of a userAgent HTTP Header vs. a
 * Mike asked if anyone knew whether any web servers limited the HTTP
 * Tony noted that although we are talking about HTTP in this meeting,
 * Group asked what was appropriate for web-services based
 * This topic was tabled for now, it was agreed that we could separate

Item 4: String Content capability a URI which he blogged this example:
 * Group discussed URIs vs. bare strings to represent capabilities
 * Concern was raised over the length issues around making every
 * Axel proposed use of the "osis" namespace, discussed his format,

version='urn:osis:infocard:2008-04'; name='urn:osis:infocard:names:openinfocard'; capabilities='+nossl +javascript-issuerpolicy'

(taken from http://ignisvulpis.blogspot.com/2008/01/id-selector-advertising-reloa...) to denote explicit support for a capability, and - to denote explicit lack of support for a capability. which correlates to the set of capabilities inherent in the ISIP v1.0 document, plus an additional capability of nossl to denote support for Relying Parties who use HTTP instead of HTTPS for information card transactions. subtraction is to be possible, there must be a finite, pre-defined, unchangeable set of capabilities encapsulated by that term, as a later redefinition of that term would become a nightmare from a product development/maintenance standpoint. here? If so, there are already created formats for such things...
 * The group discussed and expressed tentative acceptance of using +
 * Mike proposed an initial roll-up of capabilities called ISIPv1.0
 * Dale noted that ISIP v1.0 as a roll-up is useful, but if
 * Drummond noted that are we not talking about structured identifiers

Item 5: Capability Discovery capabilities within the string, a MEX endpoint could be specified, such that the Relying Party could contact the MEX endpoint and discover capabilities. simplicity is better behavior based on these capabilities round trips, but that even in the case where an endpoint was advertised and her code chose not to do the discovery, her base need of detecting presence of a selector was satisfied, which mitigates any heavy objections she might otherwise have.
 * Tony & Paul brought up the possibility that instead of specifying
 * Lots of discussion on whether this is necessary or whether
 * Questions on exactly how much an RP will really chIdeange its
 * Pamela said that as an RP she would never want to incur the extra
 * Noted that other RPs could want this later

Item 6: Note for the Record the fact that we are creating capabilities for what he called a 'moving target' -- capabilities based on a proprietary document that community members do not have control over.
 * Paul wanted it noted for the record that there is discomfort around