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.
- 1 Proposed Formats
- 2 Proposed Capabilities
- 3 Blog Posts
- 4 OSIS Meeting Notes
Proposed by: A. Nennker
|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|
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
- 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)
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.
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.
- 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.
- 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:
- 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...
- 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.