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.

Proposed Formats

Format 1

Proposed by: A. Nennker

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

Proposed Capabilities

Category	Identifier	Group	Description	Objections
Trigger Mechanism	htmltrigger	isip:v1.0	Recognizes RP with HTML selector trigger
	xhtmltrigger	isip:v1.0	Recognizes RP with XHTML selector trigger
	rpsts	isip:v1.0	Retrieves Policy and sends token to an RP STS endpoint specified with issuer and issuerPolicy (note, in Axel's proposal this was called issuerpolicy - but technically the presence of issuerpolicy is not enough to indicate presence of an RP/STS)
RP Encryption	evssl	isip:v1.0	Supports EV SSL Certificates
	ssl	isip:v1.0	Supports SSL Certificates
	nossl		Supports HTTP-only sites
	nocassl		Allows the user to choose to use a non-chaining certificate
Card Support	managedcard	isip:v1.0	Supports managed cards
	personalcard	isip:v1.0	Supports personal (self-issued) cards
Card Auditing	mandatoryaudit	isip:v1.0	Supports auditing-mandatory cards
	optionalaudit	isip:v1.0	Supports audit-optional cards
	noaudit	isip:v1.0	Supports non-auditing cards
Protocol Support	soap:1.1	isip:v1.0	Supports SOAP 1.1
	soap:1.2	isip:v1.0	Supports SOAP 1.2
	wst:1.2	isip:v1.0	Supports WS-Trust 1.2 (ISIP Version)
	wst:1.3		Supports WS-Trust 1.3 (OASIS Version)
	wsp:1.1	isip:v1.0	Supports WS-SecurityPolicy 1.1 (ISIP Version)
	wsp:1.2		Supports WS-SecurityPolicy 1.2 (OASIS Version)
Token Type Support	saml:1.0	isip:v1.0	Supports SAML 1.0 Tokens
	saml:1.1	isip:v1.0	Supports SAML 1.1 Tokens
	saml:2.0		Supports SAML 2.0 Tokens

Blog Posts

• [A. Nennker]
• [P. Dingle, 14 Jan 08]

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

Meeting: 10 January 2008 (posted by P. Dingle)

Identity Selector Capability Advertisement Meeting

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)

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.

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.

Protocol/Advertisement Mechanism

• Some discussion went on around use of a userAgent HTTP Header vs. a new, distinct HTTP header
• Mike asked if anyone knew whether any web servers limited the HTTP 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.
• Tony noted that although we are talking about HTTP in this meeting, HTTP only addresses browser based scenarios
• Group asked what was appropriate for web-services based advertisement.
• This topic was tabled for now, it was agreed that we could separate the string semantics from the advertisement mechanism, and work on the semantics first.

String Content

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

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

• The group discussed and expressed tentative acceptance of using + to denote explicit support for a capability, and - to denote explicit lack of support for a capability.
• Mike proposed an initial roll-up of capabilities called ISIPv1.0 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.
• Dale noted that ISIP v1.0 as a roll-up is useful, but if 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.
• Drummond noted that are we not talking about structured identifiers here? If so, there are already created formats for such things...

Capability Discovery

• Tony & Paul brought up the possibility that instead of specifying capabilities within the string, a MEX endpoint could be specified, such that the Relying Party could contact the MEX endpoint and discover capabilities.
• Lots of discussion on whether this is necessary or whether simplicity is better.
• Questions on exactly how much an RP will really chIdeange its behavior based on these capabilities.
• Pamela said that as an RP she would never want to incur the extra 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.
  • Noted that other RPs could want this later.

Note for the Record

• Paul wanted it noted for the record that there is discomfort around 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.