Bei der Gruppe, für die Sie eine Mitteilung verfassen, handelt es sich um eine Usenet-Gruppe. Wenn Sie in dieser Gruppe Nachrichten posten, ist Ihre E-Mail-Adresse für jeden im Internet sichtbar
In attendance at various times:
- Charles Andres
- Mike Jones
- Dale Olds
- Johannes Ernst
- Kim Cameron
- Bob RL Morgan
- Paul Bryan
- Ashish Jain
- Pamela Dingle
- Mary Ruddy
- Gerald Beuchelt
- Mrudul Uchil
- Uppili Srivinasan
Big Discussion Topics (everybody please read this):
1) User Agent strings:
We began the debate around what we could set as a testable
string in the User Agent string. There are several choices:
a) Agnostic Presence Indicator:
In this case the selector would write a string to the user
agent string that does not indicate which selector is present, only
that a selector is present. The problem with this plan is that on
uninstallation of a selector, the selector has to make a decision to
remove the selector string or not -- and to make that decision
properly, the selector would have to be aware of all other selectors
that could still be installed.
b) Two-part presence indicator
In this case each selector would create and maintain a different sub-
string in the user agent string, but all of the sub-strings start
with the same common characters. Selectors would choose a unique
identifier to follow the common characters. As a result, it would be
possible to search both agnostically for the common substring or
specifically for a given selector.
c) Two-part presence plus version
Same case as above, but there is an added versioning component.
d) Capabilities based
This term was tossed around, but not with detailed suggestions for
format or content.
2) Behaviour of the IDP in the case where a claim type has been
promised but cannot be delivered.
(note that in a perfect world this shouldn't happen, but due to the
inflexibility of the current method of specifying managed cards, we
have to live with this for a while)
In the case where an IdP has promised to deliver a certain claim type,
but they in reality don't have a value to fill, an IdP have three
choices:
a) return a valid token without an element for the missing claim
type
b) return a valid token with an empty/null string supplied for
the missing claim type
c) return a soap fault.
If the IdP was able to know the priority of the claim, they could
theoretically choose option (c) for required claims, and option (a) or
(b) for optional claims. However they IdP does not know - the RST
does not currently contain that information. Returning a SOAP fault
on an optional claim doesn't make sense, and empty values are
possibly dangerous, in that a null value could actually be a
specified, value-filled variable - in which case the IdP could be
returning false information instead of no information.
During this discussion, it was mentioned that addition of priority/
requirement of claims with the RST would be a good recommended change
to the existing ISIP protocol.
3) Token Type Equivalence
Whose responsibility is it to match equivalent token types? Does the
Selector do this or does the IdP have to have all the different token
type permutations listed in their cards?
4) 128-bit Key Size
What is the community view on 128-bit key sizes? Does anyone even
want to play ball here? What is the expected use pattern for a
component owner in Sierra Leone, for example? A number of people
expressed the need for the ability to refuse to work with such
components, but at this time, usage of a 128-bit key is not
detectable up-front... another comment was that we'd be better off
working to abolish export controls altogether...
Is there a current community consensus on interoperation? Do we need
one? Currently, 128-bit key sizes are outside the ISIP spec.
5) Platform-level "default selector" mechanism.
What do we have to do to implement a desktop client that can invoke a
user-defined default selector? In Windows? On Linux? Can we even do
interop tests of rich clients without a selector selection mechanism?
6) Kim suggested that we add a "best practice" line for IdPs that they
should accept at least one passwordless authN method.
Action Items:
- Identify an owner of a KDC who can also issue an information card
(this is for kerberos testing). Possible owners: Dale and/or RL Bob
- Mike Jones to check out which parts of requiresAppliesTo are
applicable for self-issued vs. managed cards (possibly there is a
distinction for web services based RPs vs. web-based RPs)
- Pam to add test cases around non-specification of the token type in
the card by the IdP.
- Pam to add a test case around display of standard certificates
(cases already exist for display of EV certificates)
- Mike Jones wanted confirmation from the group regarding Assymetric
binding to the Identity Provider -- is anyone else using this?
- Pam to add 2 "Rich Client Applications" tests:
1) RP is the end app, equivalent to claims based "Hello World"
2) RP requests token in order to use it in turn for a service
- Uppili to send more information to the list in regards to issues his
team has had with CardSpace and holder-of-key not working anymore
- Pam to add new condition handling case where the site name doesn't
match the name on the certificate.
- Pam to distinguish in the document between certificate errors on RP
cert vs. certificate errors on an IDP cert
- Pam to add a new case where a card import should fail if the cert
doesn't validate.
- Pam to add a new case to check that cards who don't provide claims
don't show up in the selector.
- Pam to talk to Don Schmidt regarding null values in CardSpace
- Pam to test card import/export across MS Selector Versions
- Pam to alter doc to make the "account creation via self-issued card"
and "account creation via managed card" at an IdP one case, not two
- Pam to decouple the term "accepts and creates" in the RP initial
cases
In attendance: - Charles Andres - Mike Jones - Dale Olds - Bob RL Morgan - Pamela Dingle - Mary Ruddy - Uppili Srivinasan - Jeff Bohren
Meeting Minutes --
At IIW, we spent 3.5 hrs reviewing 101 of 168 proposed tests line by line. This meeting concluded review of the remaining 67 tests.
For purposes of this discussion we used the version of the plan sent out Dec 2 by Mike Jones, (attached)
Items 1 - 12 below are issues that came up during the review of the Interop Plan. These items are active for discussion at the next meeting on Dec 17. To stay on schedule, We will drive to get closure on the plan.
1) User Agent strings: We began the debate around what we could set as a testable string in the User Agent string. There are several choices:
a) Agnostic Presence Indicator: In this case the selector would write a string to the user agent string that does not indicate which selector is present, only that a selector is present. The problem with this plan is that on uninstallation of a selector, the selector has to make a decision to remove the selector string or not -- and to make that decision properly, the selector would have to be aware of all other selectors that could still be installed.
b) Two-part presence indicator In this case each selector would create and maintain a different sub- string in the user agent string, but all of the sub-strings start with the same common characters. Selectors would choose a unique identifier to follow the common characters. As a result, it would be possible to search both agnostically for the common substring or specifically for a given selector.
c) Two-part presence plus version Same case as above, but there is an added versioning component.
d) Capabilities based This term was tossed around, but not with detailed suggestions for format or content.
2) Behaviour of the IDP in the case where a claim type has been promised but cannot be delivered.
(note that in a perfect world this shouldn't happen, but due to the inflexibility of the current method of specifying managed cards, we have to live with this for a while)
In the case where an IdP has promised to deliver a certain claim type, but they in reality don't have a value to fill, an IdP have three choices:
a) return a valid token without an element for the missing claim type b) return a valid token with an empty/null string supplied for the missing claim type c) return a soap fault.
If the IdP was able to know the priority of the claim, they could theoretically choose option (c) for required claims, and option (a) or (b) for optional claims. However they IdP does not know - the RST does not currently contain that information. Returning a SOAP fault on an optional claim doesn't make sense, and empty values are possibly dangerous, in that a null value could actually be a specified, value-filled variable - in which case the IdP could be returning false information instead of no information.
During this discussion, it was mentioned that addition of priority/ requirement of claims with the RST would be a good recommended change to the existing ISIP protocol.
3) Token Type Equivalence Whose responsibility is it to match equivalent token types? Does the Selector do this or does the IdP have to have all the different token type permutations listed in their cards?
4) 128-bit Key Size What is the community view on 128-bit key sizes? Does anyone even want to play ball here? What is the expected use pattern for a component owner in Sierra Leone, for example? A number of people expressed the need for the ability to refuse to work with such components, but at this time, usage of a 128-bit key is not detectable up-front... another comment was that we'd be better off working to abolish export controls altogether...
Is there a current community consensus on interoperation? Do we need one? Currently, 128-bit key sizes are outside the ISIP spec.
5) Platform-level "default selector" mechanism. What do we have to do to implement a desktop client that can invoke a user-defined default selector? In Windows? On Linux? Can we even do interop tests of rich clients without a selector selection mechanism?
6) Kim suggested that we add a "best practice" line for IdPs that they should accept at least one passwordless authN method.
7) multi-valued claims should be returned in the order they were presented. M$ will put up an IdP that sends multi-valued claims. We have done namespace already; avoid test collisions; will also test an unexpected multi-valued claim. we don't want to change current undertanding on existing claims (i.e. namesspace)
8) Invalid Claim values -- 'empty' is not a special case
9) Ignore padding in token -- do we merge this with whitespace, other residue around the token payload? Should be one test, but the test may test for different 'padding/characters'
10) 3 Condition Handlers for RP's dealing with lack of installation of either a selector and/or a browser extension: installed? selector no yes no browser yes no no
11) RP should react in a way that invites users to start using cards (and a pointer to getting started selecting a card selector, etc.)
12) General usability: To create an extensible, reliable, modular identity ecosystem, the community (and specfiically the leaders driving interoperability) should provide more comprehensive best practices to help develop an underlying consistency to RP sites. These include usability tests and recommendations such as:
13) what to do when logging into something you have never seen before. usability across platforms -- different features, different display, setting best practices -- is the privacy policy displayed? Can we draft a set of usability recommendations - what to do if? Out of this may come a set or Usability recommendations and tests for user-facing components.
Action Items:
- Identify an owner of a KDC who can also issue an information card (this is for kerberos testing). Possible owners: Dale and/or RL Bob
- Mike Jones to check out which parts of requiresAppliesTo are applicable for self-issued vs. managed cards (possibly there is a distinction for web services based RPs vs. web-based RPs)
- Pam to add test cases around non-specification of the token type in the card by the IdP.
- Pam to add a test case around display of standard certificates (cases already exist for display of EV certificates)
- Mike Jones wanted confirmation from the group regarding Assymetric binding to the Identity Provider -- is anyone else using this?
- Pam to add 2 "Rich Client Applications" tests: 1) RP is the end app, equivalent to claims based "Hello World" 2) RP requests token in order to use it in turn for a service
- Uppili to send more information to the list in regards to issues his team has had with CardSpace and holder-of-key not working anymore
- Pam to add new condition handling case where the site name doesn't match the name on the certificate.
- Pam to distinguish in the document between certificate errors on RP cert vs. certificate errors on an IDP cert
- Pam to add a new case where a card import should fail if the cert doesn't validate.
- Pam to add a new case to check that cards who don't provide claims don't show up in the selector.
- Pam to talk to Don Schmidt regarding null values in CardSpace
- Pam to test card import/export across MS Selector Versions
- Pam to alter doc to make the "account creation via self-issued card" and "account creation via managed card" at an IdP one case, not two
- Pam to decouple the term "accepts and creates" in the RP initial Cases.
- Mike: OpenID RPs, IdPs: Should we break up PAPE support? in one case we did (breaking out phishing) we should be consistent.
- Charles took notes. This email only goes to the new user-centric-identity-interop@googlegroups.com; A reference will be sent to OSIS general and the old Barcelona list which wlll be officially closed. The Barcelona wiki will remain up.
- Mike,Charles, Pam - Complete plan by categorizing each test as follows: - do we have a test (yes, which one show pointer) If no, then: - are we building a test? - what order will we build these tests?
Next Milestones:
December 14: Buy-in for the plan achieved among OSIS members and likely participants. December 21: Revised plan produced and published.
Regarding the item "Pam to add a new case to check that cards who don't provide claims don't show up in the selector" could we get more information about why claimlessness is considered cause for non display, and in what situations the card wouldn't be displayed?
We have discussed security tokens without claims as actually having value. An example would be a e-commerce site offers a minimal discount to employees of company A in hopes of getting increased business. The site is not interested in enforcing stringent requirements (think of all the places that will give you a discount simply for asking for the reduced price.) The ability for an employee of company A to to request a claimless security token from their IDP an know that no personal or company information was released makes the transaction look enticing. The e-commerce site didn't have to enter into some complex trust relationship with company A, they got business, Company A didn't have liability for information released, the user didn't have to release any crucial data -- everyone appears to win!
To: "user-centric-identity-interop@googlegroups.com" <user-centric-identity-interop@googlegroups.com>
Date: 12/10/07 3:03 PM
Subject: Dec 10 2007 OSIS Interoperability Meeting Minutes
OSIS User Interop Meeting - 10th December 2007
In attendance: - Charles Andres - Mike Jones - Dale Olds - Bob RL Morgan - Pamela Dingle - Mary Ruddy - Uppili Srivinasan - Jeff Bohren
Meeting Minutes --
At IIW, we spent 3.5 hrs reviewing 101 of 168 proposed tests line by line. This meeting concluded review of the remaining 67 tests.
For purposes of this discussion we used the version of the plan sent out Dec 2 by Mike Jones, (attached)
Items 1 – 12 below are issues that came up during the review of the Interop Plan. These items are active for discussion at the next meeting on Dec 17. To stay on schedule, We will drive to get closure on the plan.
1) User Agent strings: We began the debate around what we could set as a testable string in the User Agent string. There are several choices:
a) Agnostic Presence Indicator: In this case the selector would write a string to the user agent string that does not indicate which selector is present, only that a selector is present. The problem with this plan is that on uninstallation of a selector, the selector has to make a decision to remove the selector string or not -- and to make that decision properly, the selector would have to be aware of all other selectors that could still be installed.
b) Two-part presence indicator In this case each selector would create and maintain a different sub- string in the user agent string, but all of the sub-strings start with the same common characters. Selectors would choose a unique identifier to follow the common characters. As a result, it would be possible to search both agnostically for the common substring or specifically for a given selector.
c) Two-part presence plus version Same case as above, but there is an added versioning component.
d) Capabilities based This term was tossed around, but not with detailed suggestions for format or content.
2) Behaviour of the IDP in the case where a claim type has been promised but cannot be delivered.
(note that in a perfect world this shouldn't happen, but due to the inflexibility of the current method of specifying managed cards, we have to live with this for a while)
In the case where an IdP has promised to deliver a certain claim type, but they in reality don't have a value to fill, an IdP have three choices:
a) return a valid token without an element for the missing claim type b) return a valid token with an empty/null string supplied for the missing claim type c) return a soap fault.
If the IdP wtheoretically choose option (c) for required claims, and option (a) or (b) for optional claims. However they IdP does not know - the RST does not currently contain that information. Returning a SOAP fault on an optional claim doesn't make sense, and empty values are possibly dangerous, in that a null value could actually be a specified, value-filled variable - in which case the IdP could be returning false information instead of no information.
During this discussion, it was mentioned that addition of priority/ requirement of claims with the RST would be a good recommended change to the existing ISIP protocol.
3) Token Type Equivalence Whose responsibility is it to match equivalent token types? Does the Selector do this or does the IdP have to have all the different token type permutations listed in their cards?
4) 128-bit Key Size What is the community view on 128-bit key sizes? Does anyone even want to play ball here? What is the expected use pattern for a component owner in Sierra Leone, for example? A number of people expressed the need for the ability to refuse to work with such components, but at this time, usage of a 128-bit key is not detectable up-front... another comment was that we'd be better off working to abolish export controls altogether...
Is there a current community consensus on interoperation? Do we need one? Currently, 128-bit key sizes are outside the ISIP spec.
5) Platform-level "default selector" mechanism. What do we have to do to implement a desktop client that can invoke a user-defined default selector? In Windows? On Linux? Can we even do interop tests of rich clients without a selector selection mechanism?
6) Kim suggested that we add a "best practice" line for IdPs that they should accept at least one passwordless authN method.
7)
multi-valued claims should be returned in the order they were presented. M$ will put up an IdP that sends multi-valued claims. We have done namespace already; avoid test collisions; will also test an unexpected multi-valued claim. we don’t want to change current undertanding on existing claims (i.e. namesspace)
8) Invalid Claim values -- ‘empty’ is not a special case
9) Ignore padding in token -- do we merge this with whitespace, other residue around the token payload? Should be one test, but the test may test for different ‘padding/characters’
10) 3 Condition Handlers for RP’s dealing with lack of installation of either a selector and/or a browser extension: installed? selector no yes no browser yes no no
11) RP should react in a way that invites users to start using cards (and a pointer to getting started selecting a card selector, etc.)
12) General usability: To create an extensible, reliable, modular identity ecosystem, the community (and specfiically the leaders driving interoperability) should provide more comprehensive best practices to help develop an underlying consistency to RP sites. These include usability tests and recommendations such as:
13) what to do when logging into something you have never seen before. usability across platforms -- different features, different display, setting best practices -- is the privacy policy displayed? Can we draft a set of usability recommendations — what to do if? Out of this may come a set or Usability recommendations and tests for user-facing components.
Action Items:
- Identify an owner of a KDC who can also issue an information card (this is for kerberos testing). Possible owners: Dale and/or RL Bob
- Mike Jones to check out which parts of requiresAppliesTo are applicable for self-issued vs. managed cards (possibly there is a distinction for web services based RPs vs. web-based RPs)
- Pam to add test cases around non-specification of the token type in the card by the IdP.
- Pam to add a test case around display of standard certificates (cases already exist for display of EV certificates)
- Mike Jones wanted confirmation from the groupbinding to the Identity Provider -- is anyone else using this?
- Pam to add 2 "Rich Client Applications" tests: 1) RP is the end app, equivalent to claims based "Hello World" 2) RP requests token in order to use it in turn for a service
- Uppili to send more information to the list in regards to issues his team has had with CardSpace and holder-of-key not working anymore
- Pam to add new condition handling case where the site name doesn't match the name on the certificate.
- Pam to distinguish in the document between certificate errors on RP cert vs. certificate errors on an IDP cert
- Pam to add a new case where a card import should fail if the cert doesn't validate.
- Pam to add a new case to check that cards who don't provide claims don't show up in the selector.
- Pam to talk to Don Schmidt regarding null values in CardSpace
- Pam to test card import/export across MS Selector Versions
- Pam to alter doc to make the "account creation via self-issued card" and "account creation via managed card" at an IdP one case, not two
- Pam to decouple the term "accepts and creates" in the RP initial Cases.
- Mike: OpenID RPs, IdPs: Should we break up PAPE support? in one case we did (breaking out phishing) we should be consistent.
- Charles took notes. This email only goes to the new user-centric-identity-interop@googlegroups.com; A reference will be sent to OSIS general and the old Barcelona list which wlll be officially closed. The Barcelona wiki will remain up.
- Mike,Charles, Pam — Complete plan by categorizing each test as follows: - do we have a test (yes, which one show pointer) If no, then: - are we building a test? - what order will we build these tests?
Next Milestones:
December 14: Buy-in for the plan achieved among OSIS members and likely participants. December 21: Revised plan produced and published.
Wouldn't there need to be at least one claim -- the email address to send the discount coupon to, or the phone number? (2008 prediction -- discount coupons sent directly to your phone/screen).
On Dec 10, 2007 6:29 PM, Duane Buss <db...@novell.com> wrote:
> Regarding the item "Pam to add a new case to check that cards who don't > provide claims don't show up in the selector" could we get more information > about why claimlessness is considered cause for non display, and in what > situations the card wouldn't be displayed?
> We have discussed security tokens without claims as actually having > value. An example would be a e-commerce site offers a minimal discount to > employees of company A in hopes of getting increased business. The site is > not interested in enforcing stringent requirements (think of all the places > that will give you a discount simply for asking for the reduced price.) > The ability for an employee of company A to to request a claimless security > token from their IDP an know that no personal or company information was > released makes the transaction look enticing. The e-commerce site didn't > have to enter into some complex trust relationship with company A, they got > business, Company A didn't have liability for information released, the user > didn't have to release any crucial data -- everyone appears to win!
> Dec 10 2007 OSIS Interoperability Meeting Minutes
> OSIS User Interop Meeting - 10th December 2007
> In attendance: > - Charles Andres > - Mike Jones > - Dale Olds > - Bob RL Morgan > - Pamela Dingle > - Mary Ruddy > - Uppili Srivinasan > - Jeff Bohren
> Meeting Minutes --
> At IIW, we spent 3.5 hrs reviewing 101 of 168 proposed tests line by line. > This meeting concluded review of the remaining 67 tests.
> For purposes of this discussion we used the version of the plan sent out Dec > 2 by Mike Jones, (attached)
> Items 1 – 12 below are issues that came up during the review of the Interop > Plan. These items are active for discussion at the next meeting on Dec 17. > To stay on schedule, We will drive to get closure on the plan.
> 1) User Agent strings: > We began the debate around what we could set as a testable > string in the User Agent string. There are several choices:
> a) Agnostic Presence Indicator: > In this case the selector would write a string to the user > agent string that does not indicate which selector is present, only > that a selector is present. The problem with this plan is that on > uninstallation of a selector, the selector has to make a decision to > remove the selector string or not -- and to make that decision > properly, the selector would have to be aware of all other selectors > that could still be installed.
> b) Two-part presence indicator > In this case each selector would create and maintain a > different sub- > string in the user agent string, but all of the sub-strings start > with the same common characters. Selectors would choose a unique > identifier to follow the common characters. As a result, it would be > possible to search both agnostically for the common substring or > specifically for a given selector.
> c) Two-part presence plus version > Same case as above, but there is an added versioning > component.
> d) Capabilities based > This term was tossed around, but not with detailed > suggestions for > format or content.
> 2) Behaviour of the IDP in the case where a claim type has been > promised but cannot be delivered.
> (note that in a perfect world this shouldn't happen, but due to the > inflexibility of the current method of specifying managed cards, we > have to live with this for a while)
> In the case where an IdP has promised to deliver a certain claim type, > but they in reality don't have a value to fill, an IdP have three > choices:
> a) return a valid token without an element for the missing claim > type > b) return a valid token with an empty/null string supplied for > the missing claim type > c) return a soap fault.
> If the IdP was able to know the priority of the claim, they could > theoretically choose option (c) for required claims, and option (a) or > (b) for optional claims. However they IdP does not know - the RST > does not currently contain that information. Returning a SOAP fault > on an optional claim doesn't make sense, and empty values are > possibly dangerous, in that a null value could actually be a > specified, value-filled variable - in which case the IdP could be > returning false information instead of no information.
> During this discussion, it was mentioned that addition of priority/ > requirement of claims with the RST would be a good recommended change > to the existing ISIP protocol.
> 3) Token Type Equivalence > Whose responsibility is it to match equivalent token types? Does the > Selector do this or does the IdP have to have all the different token > type permutations listed in their cards?
> 4) 128-bit Key Size > What is the community view on 128-bit key sizes? Does anyone even > want to play ball here? What is the expected use pattern for a > component owner in Sierra Leone, for example? A number of people > expressed the need for the ability to refuse to work with such > components, but at this time, usage of a 128-bit key is not > detectable up-front... another comment was that we'd be better off > working to abolish export controls altogether...
> Is there a current community consensus on interoperation? Do we need > one? Currently, 128-bit key sizes are outside the ISIP spec.
> 5) Platform-level "default selector" mechanism. > What do we have to do to implement a desktop client that can invoke a > user-defined default selector? In Windows? On Linux? Can we even do > interop tests of rich clients without a selector selection mechanism?
> 6) Kim suggested that we add a "best practice" line for IdPs that they > should accept at least one passwordless authN method.
> 7)
> multi-valued claims should be returned in the order they were presented. > M$ will put up an IdP that sends multi-valued claims. We have done namespace > already; avoid test collisions; will also test an unexpected multi-valued > claim. we don't want to change current undertanding on existing claims > (i.e. namesspace)
> 8) Invalid Claim values -- 'empty' is not a special case
> 9) Ignore padding in token -- do we merge this with whitespace, other > residue around the token payload? Should be one test, but the test may test > for different 'padding/characters'
> 10) 3 Condition Handlers for RP's dealing with lack of installation of > either a selector and/or a browser extension: > installed? > selector no yes no > browser yes no no
> 11) RP should react in a way that invites users to start using cards (and a > pointer to getting started selecting a card selector, etc.)
> 12) General usability: To create an extensible, reliable, modular identity > ecosystem, the community (and specfiically the leaders driving > interoperability) should provide more comprehensive best practices to help > develop an underlying consistency to RP sites. These include usability tests > and recommendations such as:
> 13) what to do when logging into something you have never seen before. > usability across platforms -- different features, different display, setting > best practices -- is the privacy policy displayed? Can we draft a set of > usability recommendations — what to do if? > Out of this may come a set or Usability recommendations and tests for > user-facing components.
> Action Items:
> - Identify an owner of a KDC who can also issue an information card > (this is for kerberos testing). Possible owners: Dale and/or RL Bob
> - Mike Jones to check out which parts of requiresAppliesTo are > applicable for self-issued vs. managed cards (possibly there is a > distinction for web services based RPs vs. web-based RPs)
> - Pam to add test cases around non-specification of the token type in > the card by the IdP.
> - Pam to add a test case around display of standard certificates > (cases already exist for display of EV certificates)
> - Mike Jones wanted confirmation from the group regarding Assymetric > binding to the Identity Provider -- is anyone else using this?
> - Pam to add 2 "Rich Client Applications" tests: > 1) RP is the end app, equivalent to claims based "Hello > World" > 2) RP requests token in order to use it in turn for a > service
> - Uppili to send more information to the list in regards to issues his > team has had with CardSpace and holder-of-key not working anymore
> - Pam to add new condition handling case where the site name doesn't > match the name on the certificate.
> - Pam to distinguish in the document between certificate errors on RP > cert vs. certificate errors on an IDP cert
> - Pam to add a new case where a card import should fail if the cert > doesn't validate.
> - Pam to add a new case to check that cards who don't provide claims > don't show up in the selector.
> - Pam to talk to Don Schmidt regarding null values in CardSpace
> - Pam to test card import/export across MS Selector Versions
> - Pam to alter doc to make the "account creation via self-issued card" > and "account creation via managed card" at an IdP one case, not two
> - Pam to decouple the term "accepts and creates" in the RP initial > Cases.
> - Mike: OpenID RPs, IdPs: Should we break up PAPE support?
No need to send coupons, just a mini token exchange during checkout. The token exchange is not to prove who I am, it's to prove what I have, and that I have the right to have tokens issued by a given case.
A whistle-blower could use that to present a token showing association with a given company IdP without revealing identity or even PPID which could potentially be subpoenaed or tracked back to him through IdP auditing.
While overall I think that very few RPs will want claimless tokens there are a few limited use cases for them.
To: <user-centric-identity-interop@googlegroups.com>
Date: 12/11/07 8:21 AM
Subject: Re: Dec 10 2007 OSIS Interoperability Meeting Minutes
Wouldn't there need to be at least one claim -- the email address to send the discount coupon to, or the phone number? (2008 prediction -- discount coupons sent directly to your phone/screen).
On Dec 10, 2007 6:29 PM, Duane Buss <db...@novell.com> wrote:
> Regarding the item "Pam to add a new case to check that cards who don't > provide claims don't show up in the selector" could we get more information > about why claimlessness is considered cause for non display, and in what > situations the card wouldn't be displayed?
> We have discussed security tokens without claims as actually having > value. An example would be a e-commerce site offers a minimal discount to > employees of company A in hopes of getting increased business. The site is > not interested in enforcing stringent requirements (think of all the places > that will give you a discount simply for asking for the reduced price.) > The ability for an employee of company A to to request a claimless security > token from their IDP an know that no personal or company information was > released makes the transaction look enticing. The e-commerce site didn't > have to enter into some complex trust relationship with company A, they got > business, Company A didn't have liability for information released, the user > didn't have to release any crucial data -- everyone appears to win!
> Dec 10 2007 OSIS Interoperability Meeting Minutes
> OSIS User Interop Meeting - 10th December 2007
> In attendance: > - Charles Andres > - Mike Jones > - Dale Olds > - Bob RL Morgan > - Pamela Dingle > - Mary Ruddy > - Uppili Srivinasan > - Jeff Bohren
> Meeting Minutes --
> At IIW, we spent 3.5 hrs reviewing 101 of 168 proposed tests line by line. > This meeting concluded review of the remaining 67 tests.
> For purposes of this discussion we used the version of the plan sent out Dec > 2 by Mike Jones, (attached)
> Items 1 – 12 below are issues that came up during the review of the Interop > Plan. These items are active for discussion at the next meeting on Dec 17. > To stay on schedule, We will drive to get closure on the plan.
> 1) User Agent strings: > We began the debate around what we could set as a testable > string in the User Agent string. There are several choices:
> a) Agnostic Presence Indicator: > In this case the selector would write a string to the user > agent string that does not indicate which selector is present, only > that a selector is present. The problem with this plan is that on > uninstallation of a selector, the selector has to make a decision to > remove the selector string or not -- and to make that decision > properly, the selector would have to be aware of all other selectors > that could still be installed.
> b) Two-part presence indicator > In this case each selector would create and mainta> with the same common characters. Selectors would choose a unique > identifier to follow the common characters. As a result, it would be > possible to search both agnostically for the common substring or > specifically for a given selector.
> c) Two-part presence plus version > Same case as above, but there is an added versioning > component.
> d) Capabilities based > This term was tossed around, but not with detailed > suggestions for > format or content.
> 2) Behaviour of the IDP in the case where a claim type has been > promised but cannot be delivered.
> (note that in a perfect world this shouldn't happen, but due to the > inflexibility of the current method of specifying managed cards, we > have to live with this for a while)
> In the case where an IdP has promised to deliver a certain claim type, > but they in reality don't have a value to fill, an IdP have three > choices:
> a) return a valid token without an element for the missing claim > type > b) return a valid token with an empty/null string supplied for > the missing claim type > c) return a soap fault.
> If the IdP was able to know the priority of the claim, they could > theoretically choose option (c) for required claims, and option (a) or > (b) for optional claims. However they IdP does not know - the RST > does not currently contain that information. Returning a SOAP fault > on an optional claim doesn't make sense, and empty values are > possibly dangerous, in that a null value could actually be a > specified, value-filled variable - in which case the IdP could be > returning false information instead of no information.
> During this discussion, it was mentioned that addition of priority/ > requirement of claims with the RST would be a good recommended change > to the existing ISIP protocol.
> 3) Token Type Equivalence > Whose responsibility is it to match equivalent token types? Does the > Selector do this or does the IdP have to have all the different token > type permutations listed in their cards?
> 4) 128-bit Key Size > What is the community view on 128-bit key sizes? Does anyone even > want to play ball here? What is the expected use pattern for a > component owner in Sierra Leone, for example? A number of people > expressed the need for the ability to refuse to work with such > components, but at this time, usage of a 128-bit key is not > detectable up-front... another comment was that we'd be better off > working to abolish export controls altogether...
> Is there a current community consensus on interoperation? Do we need > one? Currently, 128-bit key sizes are outside the ISIP spec.
> 5) Platform-level "default selector" mechanism. > What do we have to do to implement a desktop client that can invoke a > user-defined default selector? In Windows? On Linux? Can we even do > interop tests of rich clients without a selector selection mechanism?
> 6) Kim suggested that we add a "best practice" line for IdPs that they > should accept at least one passwordless authN method.
> 7)
> multi-valued claims should be returned in the order they were presented. > M$ will put up an IdP that sends multi-valued claims. We have done namespace > already; avoid test collisions; will also test an unexpected multi-valued > claim. we don't want to change current undertanding on existing claims > (i.e. namesspace)
> 8) Invalid Claim values -- 'empty' is not a special case
> 9) Ignore padding in token -- do we merge this with whitespace, other > residue around the token payload? Should be one test, but the test may test > for different 'padding/characters'
> 10) 3 Condition Handlers for RP's dealing with lack of installation of > either a selector and/or a browser extension: > installed? > selector no yes no > browser yes no no
> 11) RP should react in a way that invites users to start using cards (and a> 12) General usability: To create an extensible, reliable, modular identity > ecosystem, the community (and specfiically the leaders driving > interoperability) should provide more comprehensive best practices to help > develop an underlying consistency to RP sites. These include usability tests > and recommendations such as:
> 13) what to do when logging into something you have never seen before. > usability across platforms -- different features, different display, setting > best practices -- is the privacy policy displayed? Can we draft a set of > usability recommendations — what to do if? > Out of this may come a set or Usability recommendations and tests for > user-facing components.
> Action Items:
> - Identify an owner of a KDC who can also issue an information card > (this is for kerberos testing). Possible owners: Dale and/or RL Bob
> - Mike Jones to check out which parts of requiresAppliesTo are > applicable for self-issued vs. managed cards (possibly there is a > distinction for web services based RPs vs. web-based RPs)
> - Pam to add test cases around non-specification of the token type in > the card by the IdP.
> - Pam to add a test case around display of standard certificates > (cases already exist for display of EV certificates)
> - Mike Jones wanted confirmation from the group regarding Assymetric > binding to the Identity Provider -- is anyone else using this?
> - Pam to add 2 "Rich Client Applications" tests: > 1) RP is the end app, equivalent to claims based "Hello > World" > 2) RP requests token in order to use it in turn for a > service
> - Uppili to send more information to the list in regards to issues his > team has had with CardSpace and holder-of-key not working anymore
> - Pam to add new condition handling case where the site name doesn't > match the name on the certificate.
> - Pam to distinguish in the document between certificate errors on RP > cert vs. certificate errors on an IDP cert
So suspect using a User Agent String is a bad idea - you want to be able to test presence of a selector - can this be in browser script - or does it need to happen in RP site?
I really think having each browser extension re-decorate the User Agent is a bad idea.
A new option is:
Common client side scriptable get_InstalledIdentitySelector(String) which allows JScript to test which selector is installed. Potentially this would need to be multi-valued to allow one to enumerate the set of installed selectors. And invocation would allow a prefered selector to be chosen when more than one is present.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
To: User-Centric Identity Interop <user-centric-identity-interop@googlegroups.com>
Date: 12/10/2007 01:48 PM
Subject: Action Items & Discussion Items from the IIW Interop Session
OSIS Meeting Action Items - 4th December 2007
In attendance at various times: - Charles Andres - Mike Jones - Dale Olds - Johannes Ernst - Kim Cameron - Bob RL Morgan - Paul Bryan - Ashish Jain - Pamela Dingle - Mary Ruddy - Gerald Beuchelt - Mrudul Uchil - Uppili Srivinasan.
Big Discussion Topics (everybody please read this):
1) User Agent strings: We began the debate around what we could set as a testable string in the User Agent string. There are several choices:
a) Agnostic Presence Indicator: In this case the selector would write a string to the user agent string that does not indicate which selector is present, only that a selector is present. The problem with this plan is that on uninstallation of a selector, the selector has to make a decision to remove the selector string or not -- and to make that decision properly, the selector would have to be aware of all other selectors that could still be installed.
b) Two-part presence indicator In this case each selector would create and maintain a different sub- string in the user agent string, but all of the sub-strings start with the same common characters. Selectors would choose a unique identifier to follow the common characters. As a result, it would be possible to search both agnostically for the common substring or specifically for a given selector.
c) Two-part presence plus version Same case as above, but there is an added versioning component.
d) Capabilities based This term was tossed around, but not with detailed suggestions for format or content.
2) Behaviour of the IDP in the case where a claim type has been promised but cannot be delivered.
(note that in a perfect world this shouldn't happen, but due to the inflexibility of the current method of specifying managed cards, we have to live with this for a while)
In the case where an IdP has promised to deliver a certain claim type, but they in reality don't have a value to fill, an IdP have three choices:
a) return a valid token without an element for the missing claim type, b) return a valid token with an empty/null string supplied for the missing claim type c) return a soap fault.
If the IdP was able to know the priority of the claim, they could theoretically choose option (c) for required claims, and option (a) or (b) for optional claims. However they IdP does not know - the RST does not currently contain that information. Returning a SOAP fault on an optional claim doesn't make sense, and empty values are possibly dangerous, in that a null value could actually be a specified, value-filled variable - in which case the IdP could be returning false information instead of no information.
During this discussion, it was mentioned that addition of priority/ requirement of claims with the RST would be a good recommended change to the existing ISIP protocol.
3) Token Type Equivalence Whose responsibility is it to match equivalent token types? Does the Selector do this or does the IdP have to have all the different token type permutations listed in their cards?
4) 128-bit Key Size What is the community view on 128-bit key sizes? Does anyone even want to play ball here? What is the expected use pattern for a component owner in Sierra Leone, for example? A number of people expressed the need for the ability to refuse to work with such components, but at this time, usage of a 128-bit key is not detectable up-front... another comment was that we'd be better off working to abolish export controls altogether...
Is there a current community consensus on interoperation? Do we need one? Currently, 128-bit key sizes are outside the ISIP spec.
5) Platform-level "default selector" mechanism. What do we have to do to implement a desktop client that can invoke a user-defined default selector? In Windows? On Linux? Can we even do interop tests of rich clients without a selector selection mechanism?
6) Kim suggested that we add a "best practice" line for IdPs that they should accept at least one passwordless authN method.
Action Items:
- Identify an owner of a KDC who can also issue an information card (this is for kerberos testing). Possible owners: Dale and/or RL Bob
- Mike Jones to check out which parts of requiresAppliesTo are applicable for self-issued vs. managed cards (possibly there is a distinction for web services based RPs vs. web-based RPs)
- Pam to add test cases around non-specification of the token type in the card by the IdP.
- Pam to add a test case around display of standard certificates (cases already exist for display of EV certificates)
- Mike Jones wanted confirmation from the group regarding Assymetric binding to the Identity Provider -- is anyone else using this?
- Pam to add 2 "Rich Client Applications" tests: 1) RP is the end app, equivalent to claims based "Hello World" 2) RP requests token in order to use it in turn for a service
- Uppili to send more information to the list in regards to issues his team has had with CardSpace and holder-of-key not working anymore
- Pam to add new condition handling case where the site name doesn't match the name on the certificate.
- Pam to distinguish in the document between certificate errors on RP cert vs. certificate errors on an IDP cert
- Pam to add a new case where a card import should fail if the cert doesn't validate.
- Pam to add a new case to check that cards who don't provide claims don't show up in the selector.
- Pam to talk to Don Schmidt regarding null values in CardSpace
- Pam to test card import/export across MS Selector Versions
- Pam to alter doc to make the "account creation via self-issued card" and "account creation via managed card" at an IdP one case, not two
- Pam to decouple the term "accepts and creates" in the RP initial cases
I think we need a use-case other than 'whistle blower' if this needs to be built into the RP. Otherwise, they have no incentive to do so, unless required by law. Is there any downside to this - i.e. Could such an anonymous connection be used to open a wormhole that could potentially leak out proprietary data?
On 12/11/07 11:50 AM, "Duane Buss" <db...@novell.com> wrote:
No need to send coupons, just a mini token exchange during checkout. The token exchange is not to prove who I am, it's to prove what I have, and that I have the right to have tokens issued by a given case.
A whistle-blower could use that to present a token showing association with a given company IdP without revealing identity or even PPID which could potentially be subpoenaed or tracked back to him through IdP auditing.
While overall I think that very few RPs will want claimless tokens there are a few limited use cases for them.
-Duane
>>>
From: "Charles Andres" <andres.char...@gmail.com> To: <user-centric-identity-interop@googlegroups.com> Date: 12/11/07 8:21 AM Subject: Re: Dec 10 2007 OSIS Interoperability Meeting Minutes
Wouldn't there need to be at least one claim -- the email address to send the discount coupon to, or the phone number? (2008 prediction -- discount coupons sent directly to your phone/screen).
On Dec 10, 2007 6:29 PM, Duane Buss <db...@novell.com> wrote:
> Regarding the item "Pam to add a new case to check that cards who don't > provide claims don't show up in the selector" could we get more information > about why claimlessness is considered cause for non display, and in what > situations the card wouldn't be displayed?
> We have discussed security tokens without claims as actually having > value. An example would be a e-commerce site offers a minimal discount to > employees of company A in hopes of getting increased business. The site is > not interested in enforcing stringent requirements (think of all the places > that will give you a discount simply for asking for the reduced price.) > The ability for an employee of company A to to request a claimless security > token from their IDP an know that no personal or company information was > released makes the transaction look enticing. The e-commerce site didn't > have to enter into some complex trust relationship with company A, they got > business, Company A didn't have liability for information released, the user > didn't have to release any crucial data -- everyone appears to win!
> Dec 10 2007 OSIS Interoperability Meeting Minutes
> OSIS User Interop Meeting - 10th December 2007
> In attendance: > - Charles Andres > - Mike Jones > - Dale Olds > - Bob RL Morgan > - Pamela Dingle > - Mary Ruddy > - Uppili Srivinasan > - Jeff Bohren
> Meeting Minutes --
> At IIW, we spent 3.5 hrs reviewing 101 of 168 proposed tests line by line. > This meeting concluded review of the remaining 67 tests.
> For purposes of this discussion we used the version of the plan sent out Dec > 2 by Mike Jones, (attached)
> Items 1 - 12 below are issues that came up during the review of the Interop > Plan. These items are active for discussion at the next meeting on Dec 17. > To stay on schedule, We will drive to get closure on the plan.
> 1) User Agent strings: > We began the debate around what we could set as a testable > string in the User Agent string. There are several choices:
> a) Agnostic Presence Indicator: > In this case the selector would write a string to the user > agent string that does not indicate which selector is present, only > that a selector is present. The problem with this plan is that on > uninstallation of a selector, the selector has to make a decision to > remove the selector string or not -- and to make that decision > properly, the selector would have to be aware of all other selectors > that could still be installed.
> b) Two-part presence indicator > In this case each selector would create and maintain a > different sub- > string in the user agent string, but all of the sub-strings start > with the same common characters. Selectors would choose a unique > identifier to follow the common characters. As a result, it would be > possible to search both agnostically for the common substring or > specifically for a given selector.
> c) Two-part presence plus version > Same case as above, but there is an added versioning > component.
> d) Capabilities based > This term was tossed around, but not with detailed > suggestions for > format or content.
> 2) Behaviour of the IDP in the case where a claim type has been > promised but cannot be delivered.
> (note that in a perfect world this shouldn't happen, but due to the > inflexibility of the current method of specifying managed cards, we > have to live with this for a while)
> In the case where an IdP has promised to deliver a certain claim type, > but they in reality don't have a value to fill, an IdP have three > choices:
> a) return a valid token without an element for the missing claim > type > b) return a valid token with an empty/null string supplied for > the missing claim type > c) return a soap fault.
> If the IdP was able to know the priority of the claim, they could > theoretically choose option (c) for required claims, and option (a) or > (b) for optional claims. However they IdP does not know - the RST > does not currently contain that information. Returning a SOAP fault > on an optional claim doesn't make sense, and empty values are > possibly dangerous, in that a null value could actually be a > specified, value-filled variable - in which case the IdP could be > returning false information instead of no information.
> During this discussion, it was mentioned that addition of priority/ > requirement of claims with the RST would be a good recommended change > to the existing ISIP protocol.
> 3) Token Type Equivalence > Whose responsibility is it to match equivalent token types? Does the > Selector do this or does the IdP have to have all the different token > type permutations listed in their cards?
> 4) 128-bit Key Size > What is the community view on 128-bit key sizes? Does anyone even > want to play ball here? What is the expected use pattern for a > component owner in Sierra Leone, for example? A number of people > expressed the need for the ability to refuse to work with such > components, but at this time, usage of a 128-bit key is not > detectable up-front... another comment was that we'd be better off > working to abolish export controls altogether...
> Is there a current community consensus on interoperation? Do we need > one? Currently, 128-bit key sizes are outside the ISIP spec.
> 5) Platform-level "default selector" mechanism. > What do we have to do to implement a desktop client that can invoke a > user-defined default selector? In Windows? On Linux? Can we even do > interop tests of rich clients without a selector selection mechanism?
> 6) Kim suggested that we add a "best practice" line for IdPs that they > should accept at least one passwordless authN method.
> 7)
> multi-valued claims should be returned in the order they were presented. > M$ will put up an IdP that sends multi-valued claims. We have done namespace > already; avoid test collisions; will also test an unexpected multi-valued > claim. we don't want to change current undertanding on existing claims > (i.e. namesspace)
> 8) Invalid Claim values -- 'empty' is not a special case
> 9) Ignore padding in token -- do we merge this with whitespace, other > residue around the token payload? Should be one test, but the test may test > for different 'padding/characters'
> 10) 3 Condition Handlers for RP's dealing with lack of installation of > either a selector and/or a browser extension: > installed? > selector no yes no > browser yes no no
> 11) RP should react in a way that invites users to start using cards (and a > pointer to getting started selecting a card selector, etc.)
> 12) General usability: To create an extensible, reliable, modular identity > ecosystem, the community (and specfiically the leaders driving > interoperability) should provide more comprehensive best practices to help > develop an underlying consistency to RP sites. These include usability tests > and recommendations such as:
> 13) what to do when logging into something you have never seen before. > usability across platforms -- different features, different display, setting > best practices -- is the privacy policy displayed? Can we draft a set of > usability recommendations - what to do if? > Out of this may come a set or Usability recommendations and tests for > user-facing components.
> Action Items:
> - Identify an owner of a KDC who can also issue an information card > (this is for kerberos testing). Possible owners: Dale and/or RL Bob
> - Mike Jones to check out which parts of requiresAppliesTo are > applicable for self-issued vs. managed cards (possibly there is a > distinction for web services based RPs vs. web-based RPs)
> - Pam to add test cases around non-specification of the token type in > the card by the IdP.
> - Pam to add a test case around display of standard certificates > (cases already exist for display of EV certificates)
> - Mike Jones wanted confirmation from the group regarding Assymetric > binding to the Identity Provider -- is anyone else using this?
My recollection around this action item was merely that we test the case where in the absence of claims, the selector properly considers token type as the selection factor for card highlighting. Perhaps this action item was misquoted?
Cheers,
Pam
On 12/11/07, Charles Andres <CAnd...@parityinc.net> wrote:
> I think we need a use-case other than 'whistle blower' if this needs to > be built into the RP. Otherwise, they have no incentive to do so, unless > required by law. Is there any downside to this — i.e. Could such an > anonymous connection be used to open a wormhole that could potentially leak > out proprietary data?
> On 12/11/07 11:50 AM, "Duane Buss" <db...@novell.com> wrote:
> No need to send coupons, just a mini token exchange during checkout. The > token exchange is not to prove who I am, it's to prove what I have, and that > I have the right to have tokens issued by a given case.
> A whistle-blower could use that to present a token showing association > with a given company IdP without revealing identity or even PPID which could > potentially be subpoenaed or tracked back to him through IdP auditing.
> While overall I think that very few RPs will want claimless tokens there > are a few limited use cases for them.
> *Date: * 12/11/07 8:21 AM > *Subject: * Re: Dec 10 2007 OSIS Interoperability Meeting > Minutes
> Wouldn't there need to be at least one claim -- the email address to > send the discount coupon to, or the phone number? (2008 prediction -- > discount coupons sent directly to your phone/screen).
> On Dec 10, 2007 6:29 PM, Duane Buss <db...@novell.com> wrote:
> > Regarding the item "Pam to add a new case to check that cards who > don't > > provide claims don't show up in the selector" could we get more > information > > about why claimlessness is considered cause for non display, and in what > > situations the card wouldn't be displayed?
> > We have discussed security tokens without claims as actually having > > value. An example would be a e-commerce site offers a minimal discount > to > > employees of company A in hopes of getting increased business. The > site is > > not interested in enforcing stringent requirements (think of all the > places > > that will give you a discount simply for asking for the reduced price.) > > The ability for an employee of company A to to request a claimless > security > > token from their IDP an know that no personal or company information was > > released makes the transaction look enticing. The e-commerce site > didn't > > have to enter into some complex trust relationship with company A, they > got > > business, Company A didn't have liability for information released, the > user > > didn't have to release any crucial data -- everyone appears to win!
> > Dec 10 2007 OSIS Interoperability Meeting Minutes
> > OSIS User Interop Meeting - 10th December 2007
> > In attendance: > > - Charles Andres > > - Mike Jones > > - Dale Olds > > - Bob RL Morgan > > - Pamela Dingle > > - Mary Ruddy > > - Uppili Srivinasan > > - Jeff Bohren
> > Meeting Minutes --
> > At IIW, we spent 3.5 hrs reviewing 101 of 168 proposed tests line by > line. > > This meeting concluded review of the remaining 67 tests.
> > For purposes of this discussion we used the version of the plan sent out > Dec > > 2 by Mike Jones, (attached)
> > Items 1 – 12 below are issues that came up during the review of the > Interop > > Plan. These items are active for discussion at the next meeting on Dec > 17. > > To stay on schedule, We will drive to get closure on the plan.
> > 1) User Agent strings: > > We began the debate around what we could set as a testable > > string in the User Agent string. There are several choices:
> > a) Agnostic Presence Indicator: > > In this case the selector would write a string to the > user > > agent string that does not indicate which selector is present, only > > that a selector is present. The problem with this plan is that on > > uninstallation of a selector, the selector has to make a decision to > > remove the selector string or not -- and to make that decision > > properly, the selector would have to be aware of all other selectors > > that could still be installed.
> > b) Two-part presence indicator > > In this case each selector would create and maintain a > > different sub- > > string in the user agent string, but all of the sub-strings start > > with the same common characters. Selectors would choose a unique > > identifier to follow the common characters. As a result, it would be > > possible to search both agnostically for the common substring or > > specifically for a given selector.
> > c) Two-part presence plus version > > Same case as above, but there is an added versioning > > component.
> > d) Capabilities based > > This term was tossed around, but not with detailed > > suggestions for > > format or content.
> > 2) Behaviour of the IDP in the case where a claim type has been > > promised but cannot be delivered.
> > (note that in a perfect world this shouldn't happen, but due to the > > inflexibility of the current method of specifying managed cards, we > > have to live with this for a while)
> > In the case where an IdP has promised to deliver a certain claim type, > > but they in reality don't have a value to fill, an IdP have three > > choices:
> > a) return a valid token without an element for the missing claim > > type > > b) return a valid token with an empty/null string supplied for > > the missing claim type > > c) return a soap fault.
> > If the IdP was able to know the priority of the claim, they could > > theoretically choose option (c) for required claims, and option (a) or > > (b) for optional claims. However they IdP does not know - the RST > > does not currently contain that information. Returning a SOAP fault > > on an optional claim doesn't make sense, and empty values are > > possibly dangerous, in that a null value could actually be a > > specified, value-filled variable - in which case the IdP could be > > returning false information instead of no information.
> > During this discussion, it was mentioned that addition of priority/ > > requirement of claims with the RST would be a good recommended change > > to the existing ISIP protocol.
> > 3) Token Type Equivalence > > Whose responsibility is it to match equivalent token types? Does the > > Selector do this or does the IdP have to have all the different token > > type permutations listed in their cards?
> > 4) 128-bit Key Size > > What is the community view on 128-bit key sizes? Does anyone even > > want to play ball here? What is the expected use pattern for a > > component owner in Sierra Leone, for example? A number of people > > expressed the need for the ability to refuse to work with such > > components, but at this time, usage of a 128-bit key is not > > detectable up-front... another comment was that we'd be better off > > working to abolish export controls altogether...
> > Is there a current community consensus on interoperation? Do we need > > one? Currently, 128-bit key sizes are outside the ISIP spec.
> > 5) Platform-level "default selector" mechanism. > > What do we have to do to implement a desktop client that can invoke a > > user-defined default selector? In Windows? On Linux? Can we even do > > interop tests of rich clients without a selector selection mechanism?
> > 6) Kim suggested that we add a "best practice" line for IdPs that they > > should accept at least one passwordless authN method.
> > 7)
> > multi-valued claims should be returned in the order they were > presented. > > M$ will put up an IdP that sends multi-valued claims. We have done > namespace > > already; avoid test collisions; will also test an unexpected > multi-valued > > claim. we don't want to change current undertanding on existing claims > > (i.e. namesspace)
> > 8) Invalid Claim values -- 'empty' is not a special case
> > 9) Ignore padding in token -- do we merge this with whitespace, other > > residue around the token payload? Should be one test, but the test may > test > > for different 'padding/characters'
> > 10) 3 Condition Handlers for RP's dealing with lack of installation of > > either a selector and/or a browser extension: > > installed? > > selector no yes no > > browser yes no no
> > 11) RP should react in a way that invites users to start using cards > (and a > > pointer to getting started selecting a card selector, etc.)
> > 12) General usability: To create an extensible, reliable, modular > identity > > ecosystem, the community (and specfiically the leaders driving > > interoperability) should provide more comprehensive best practices to > help > > develop an underlying consistency to RP sites. These include usability > tests > > and recommendations such as:
> > 13) what to do when logging into something you have never seen before. > > usability across platforms -- different features, different display, > setting > > best practices -- is the privacy policy displayed? Can we draft a set of > > usability
I think there is no need for the RP to know which id selector is
installed. The user chooses which selector should be used not the RP.
I don't like the user-agent pollution idea neither. I prefer a http
header like "X-ID-Selector".
You can see this implemented in the current version of the
openinfocard id selector.
http://ignisvulpis.blogspot.com/2007/12/http-header-x-id-selector.html The openinfocard implementation currently adds the header regardless
of which id selector is chosen by the user, but this is easy to
improve. (if all id selectors use and obey the same preferences
settings: e.g.: identityselector.contractid see the url about:config
in Firefox)
To: <user-centric-identity-interop@googlegroups.com>
Date: 12/11/07 3:18 PM
Subject: Re: Dec 10 2007 OSIS Interoperability Meeting Minutes
My recollection around this action item was merely that we test the case where in the absence of claims, the selector properly considers token type as the selection factor for card highlighting. Perhaps this action item was misquoted?
Cheers,
Pam
On 12/11/07, Charles Andres <CAnd...@parityinc.net> wrote:
I think we need a use-case other than 'whistle blower' if this needs to be built into the RP. Otherwise, they have no incentive to do so, unless required by law. Is there any downside to this — i.e. Could such an anonymous connection be used to open a wormhole that could potentially leak out proprietary data?
On 12/11/07 11:50 AM, "Duane Buss" <db...@novell.com > wrote:
No need to send coupons, just a mini token exchange during checkout. The token exchange is not to prove who I am, it's to prove what I have, and that I have the right to have tokens issued by a given case.
A whistle-blower could use that to present a token showing association with a given company IdP without revealing identity or even PPID which could potentially be subpoenaed or tracked back to him through IdP auditing.
While overall I think that very few RPs will want claimless tokens there are a few limited use cases for them.
-Duane
>>>
From: "Charles Andres" <andres.char...@gmail.com> To: <user-centric-identity-interop@googlegroups.com > Date: 12/11/07 8:21 AM Subject: Re: Dec 10 2007 OSIS Interoperability Meeting Minutes
Wouldn't there need to be at least one claim -- the email address to send the discount coupon to, or the phone number? (2008 prediction -- discount coupons sent directly to your phone/screen).
On Dec 10, 2007 6:29 PM, Duane Buss <db...@novell.com> wrote:
> Regarding the item "Pam to add a new case to check that cards who don't > provide claims don't show up in the selector" could we get more information > about why claimlessness is considered cause for non display, and in what > situations the card wouldn't be displayed?
> We have discussed security tokens without claims as actually having > value. An example would be a e-commerce site offers a minimal discount to > employees of company A in hopes of getting increased business. The site is > not interested in enforcing stringent requirements (think of all the places > that will give you a discount simply for asking for the reduced price.) > The ability for an employee of company A to to request a claimless security > token from their IDP an know that no personal or company information was > released makes the transaction look enticing. The e-commerce site didn't > have to enter into some complex trust relationship with company A, they got > business, Company A didn't have liability for information released, the user > didn't have to release any crucial data -- everyone appears to win!
> Dec 10 2007 OSIS Interoperability Meeting Minutes
> OSIS User Interop Meeting - 10th December 2007
> In attendance: > - Charles Andres > - Mike Jones > - Dale Olds > - Bob RL Morgan > - Pamela Dingle > - Mary Ruddy > - Uppili Srivinasan > - Jeff Bohren
> Meeting Minutes --
> At IIW, we spent > For purposes of this discussion we used the version of the plan sent out Dec > 2 by Mike Jones, (attached)
> Items 1 – 12 below are issues that came up during the review of the Interop > Plan. These items are active for discussion at the next meeting on Dec 17. > To stay on schedule, We will drive to get closure on the plan.
> 1) User Agent strings: > We began the debate around what we could set as a testable > string in the User Agent string. There are several choices:
> a) Agnostic Presence Indicator: > In this case the selector would write a string to the user > agent string that does not indicate which selector is present, only > that a selector is present. The problem with this plan is that on > uninstallation of a selector, the selector has to make a decision to > remove the selector string or not -- and to make that decision > properly, the selector would have to be aware of all other selectors > that could still be installed.
> b) Two-part presence indicator > In this case each selector would create and maintain a > different sub- > string in the user agent string, but all of the sub-strings start > with the same common characters. Selectors would choose a unique > identifier to follow the common characters. As a result, it would be > possible to search both agnostically for the common substring or > specifically for a given selector.
> c) Two-part presence plus version > Same case as above, but there is an added versioning > component.
> d) Capabilities based > This term was tossed around, but not with detailed > suggestions for > format or content.
> 2) Behaviour of the IDP in the case where a claim type has been > promised but cannot be delivered.
> (note that in a perfect world this shouldn't happen, but due to the > inflexibility of the current method of specifying managed cards, we > have to live with this for a while)
> In the case where an IdP has promised to deliver a certain claim type, > but they in reality don't have a value to fill, an IdP have three > choices:
> a) return a valid token without an element for the missing claim > type > b) return a valid token with an empty/null string supplied for > the missing claim type > c) return a soap fault.
> If the IdP was able to know the priority of the claim, they could > theoretically choose option (c) for required claims, and option (a) or > (b) for optional claims. However they IdP does not know - the RST > does not currently contain that information. Returning a SOAP fault > on an optional claim doesn't make sense, and empty values are > possibly dangerous, in that a null value could actually be a > specified, value-filled variable - in which case the IdP could be > returning false information instead of no information.
> During this discussion, it was mentioned that addition of priority/ > requirement of claims with the RST would be a good recommended change > to the existing ISIP protocol.
> 3) Token Type Equivalence > Whose responsibility is it to match equivalent token types? Does the > Selector do this or does the IdP have to have all the different token > type permutations listed in their cards?
> 4) 128-bit Key Size > What is the community view on 128-bit key sizes? Does anyone even > want to play ball here? What is the expected use pattern for a > component owner in Sierra Leone, for example? A number of people > expressed the need for the ability to refuse to work with such > components, but at this time, usage of a 128-bit key is not > detectable up-front... another comment was that we'd be better off > working to abolish export controls altogether...
> Is there a current community consensus on interoperation? Do we need > one? Currently, 128-bit key sizes are outside the ISIP spec.
> 5) Platform-level "default selector" mechanism. > What do we have to do to imp> user-defined default selector? In Windows? On Linux? Can we even do > interop tests of rich clients without a selector selection mechanism?
> 6) Kim suggested that we add a "best practice" line for IdPs that they > should accept at least one passwordless authN method.
> 7)
> multi-valued claims should be returned in the order they were presented. > M$ will put up an IdP that sends multi-valued claims. We have done namespace > already; avoid test collisions; will also test an unexpected multi-valued > claim. we don't want to change current undertanding on existing claims > (i.e. namesspace)
> 8) Invalid Claim values -- 'empty' is not a special case
> 9) Ignore padding in token -- do we merge this with whitespace, other > residue around the token payload? Should be one test, but the test may test > for different 'padding/characters'
> 10) 3 Condition Handlers for RP's dealing with lack of installation of > either a selector and/or a browser extension: > installed? > selector no yes no > browser yes no no
> 11) RP should react in a way that invites users to start using cards (and a > pointer to getting started selecting a card selector, etc.)
> 12) General usability: To create an extensible, reliable, modular identity > ecosystem, the community (and specfiically the leaders driving > interoperability) should provide more comprehensive best practices to help > develop an underlying consistency to RP sites. These include usability tests > and recommendations such as:
> 13) what to do when logging into something you have never seen before. > usability across platforms -- different features, different display, setting > best practices -- is the privacy policy displayed? Can we draft a set of > usability recommendations — what to do if? > Out of this may come a set or Usability recommendations and tests for > user-facing components.
> Action Items:
> - Identify an owner of a KDC who can also issue an information card > (this is for kerberos
As a firefox user I have an add-on which allows me to lie about which browser I'm using, to game websites into working properly. I don't think we really want to perpetuate this model and allow or require RP's to test for particular selectors. As an RP implementer I would prefer to check for presence of a selector and possibly it's capabilities. Based on it's presence or capabilities my RP can take action. Capabilities based functionality makes unit testing for each side easier, and much more deterministic. I hate the current process of testing my RP with every selector just to see if they play nice. When we have a platform level selector selector that component can be responsible for managing the capabilities advertisement. There are minor gottchas with both Tony's and Axel's proposals for which I don't see obvious solutions. Sending the capabilities in a header string might provide RPs with another data point for a creating a client fingerprint. Using client side javascript might fail because I have disabled javascript (which I personally often do).
Subject: Re: Action Items & Discussion Items from the IIW Interop Session
So suspect using a User Agent String is a bad idea - you want to be able to test presence of a selector - can this be in browser script - or does it need to happen in RP site?
I really think having each browser extension re-decorate the User Agent is a bad idea. A new option is: Common client side scriptable get_InstalledIdentitySelector(String) which allows JScript to test which selector is installed. Potentially this would need to be multi-valued to allow one to enumerate the set of installed selectors. And invocation would allow a prefered selector to be chosen when more than one is present.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Action Items & Discussion Items from the IIW Interop Session
OSIS Meeting Action Items - 4th December 2007
In attendance at various times: - Charles Andres - Mike Jones - Dale Olds - Johannes Ernst - Kim Cameron - Bob RL Morgan - Paul Bryan - Ashish Jain - Pamela Dingle - Mary Ruddy - Gerald Beuchelt - Mrudul Uchil - Uppili Srivinasan
Big Discussion Topics (everybody please read this):
1) User Agent strings: We began the debate around what we could set as a testable string in the User Agent string. There are several choices:
a) Agnostic Presence Indicator: In this case the selector would write a string to the user agent string that does not indicate which selector is present, only that a selector is present. The problem with this plan is that on uninstallation of a selector, the selector has to make a decision to remove the selector string or not -- and to make that decision properly, the selector would have to be aware of all other selectors that could still be installed.
b) Two-part presence indicator In this case each selector would create and maintain a different sub- string in the user agent string, but all of the sub-strings start with the same common characters. Selectors would choose a unique identifier to follow the common characters. As a result, it would be possible to search both agnostically for the common substring or specifically for a given selector.
c) Two-part presence plus version Same case as above, but there is an added versioning component.
d) Capabilities based This term was tossed around, but not with detailed suggestions for format or content.
2) Behaviour of the IDP in the case where a claim type has been promised but cannot be delivered.
(note that in a perfect world this shouldn't happen, but due to the inflexibility of the current method of specifying managed cards, we have to live with this for a while)
In the case where an IdP has promised to deliver a certain claim type, but they in reality don't have a value to fill, an IdP have three choices:
a) return a valid token without an element for the missing claim type b) return a valid token with an empty/null string supplied for the missing claim type c) return a soap fault.
If the IdP was able to know the priority of the claim, they could theoretically choose option (c) for required claims, and option (a) or (b) for optional claims. However they IdP does not know - the RST does not currently contain that information. Returning a SOAP fault on an optional claim doesn't make sense, and empty values are possibly dangerous, in that a null value could actually be a specified, value-filled variable - in which case the IdP could be returning false information instead of no information.
During this discussion, it was mentioned that addition of priority/ requirement of claims with the RST would be a good recommended change to the existing ISIP protocol.
3) Token Type Equivalence Whose responsibility is it to match equivalent token types? Does the Selector do this or does the IdP have to have all the different token type permutations listed in their cards?
4) 128-bit Key Size What is the community view on 128-bit key sizes? Does anyone even want to play ball here? What is the expected use pattern for a component owner in Sierra Leone, for example? A number of people expressed the need for the ability to refuse to work with such components, but at this time, usage of a 128-bit key is not detectable up-front... another comment was that we'd be better off working to abolish export controls altogether...
Is there a current community consensus on interoperation? Do we need one? Currently, 128-bit key sizes are outside the ISIP spec.
5) Platform-level "default selector" mechanism. What do we have to do to implement a desktop client that can invoke a user-defined default selector? In Windows? On Linux? Can we even do interop tests of rich clients without a selector selection mechanism?
6) Kim suggested that we add a "best practice" line for IdPs that they should accept at least one passwordless authN method.
Action Items:
- Identify an owner of a KDC who can also issue an information card (this is for kerberos testing). Possible owners: Dale and/or RL Bob
- Mike Jones to check out which parts of requiresAppliesTo are applicable for self-issued vs. managed cards (possibly there is a distinction for web services based RPs vs. web-based RPs)
- Pam to add test cases around non-specification of the token type in the card by the IdP.
- Pam to add a test case around display of standard certificates (cases already exist for display of EV certificates)
- Mike Jones wanted confirmation from the group regarding Assymetric binding to the Identity Provider -- is anyone else using this?
- Pam to add 2 "Rich Client Applications" tests: 1) RP is the end app, equivalent to claims based "Hello World" 2) RP requests token in order to use it in turn for a service
- Uppili to send more information to the list in regards to issues his team has had with CardSpace and holder-of-key not working anymore
- Pam to add new condition handling case where the site name doesn't match the name on the certificate.
- Pam to distinguish in the document between certificate errors on RP cert vs. certificate errors on an IDP cert
- Pam to add a new case where a card import should fail if the cert doesn't validate.
- Pam to add a new case to check that cards who don't provide claims don't show up in the selector.
- Pam to talk to Don Schmidt regarding null values in CardSpace
- Pam to test card import/export across MS Selector Versions
- Pam to alter doc to make the "account creation via self-issued card" and "account creation via managed card" at an IdP one case, not two
- Pam to decouple the term "accepts and creates" in the RP initial cases
Call is going on right now; same 712 945 0210 number 67472255
------ Forwarded Message From: Charles Andres <CAnd...@parityinc.net> Reply-To: <user-centric-identity-interop@googlegroups.com> Date: Mon, 10 Dec 2007 14:03:02 -0800 To: <user-centric-identity-interop@googlegroups.com> Conversation: Dec 10 2007 OSIS Interoperability Meeting Minutes Subject: Dec 10 2007 OSIS Interoperability Meeting Minutes
OSIS User Interop Meeting - 10th December 2007
In attendance: - Charles Andres - Mike Jones - Dale Olds - Bob RL Morgan - Pamela Dingle - Mary Ruddy - Uppili Srivinasan - Jeff Bohren
Meeting Minutes --
At IIW, we spent 3.5 hrs reviewing 101 of 168 proposed tests line by line. This meeting concluded review of the remaining 67 tests.
For purposes of this discussion we used the version of the plan sent out Dec 2 by Mike Jones, (attached)
Items 1 - 12 below are issues that came up during the review of the Interop Plan. These items are active for discussion at the next meeting on Dec 17. To stay on schedule, We will drive to get closure on the plan.
1) User Agent strings: We began the debate around what we could set as a testable string in the User Agent string. There are several choices:
a) Agnostic Presence Indicator: In this case the selector would write a string to the user agent string that does not indicate which selector is present, only that a selector is present. The problem with this plan is that on uninstallation of a selector, the selector has to make a decision to remove the selector string or not -- and to make that decision properly, the selector would have to be aware of all other selectors that could still be installed.
b) Two-part presence indicator In this case each selector would create and maintain a different sub- string in the user agent string, but all of the sub-strings start with the same common characters. Selectors would choose a unique identifier to follow the common characters. As a result, it would be possible to search both agnostically for the common substring or specifically for a given selector.
c) Two-part presence plus version Same case as above, but there is an added versioning component.
d) Capabilities based This term was tossed around, but not with detailed suggestions for format or content.
2) Behaviour of the IDP in the case where a claim type has been promised but cannot be delivered.
(note that in a perfect world this shouldn't happen, but due to the inflexibility of the current method of specifying managed cards, we have to live with this for a while)
In the case where an IdP has promised to deliver a certain claim type, but they in reality don't have a value to fill, an IdP have three choices:
a) return a valid token without an element for the missing claim type b) return a valid token with an empty/null string supplied for the missing claim type c) return a soap fault.
If the IdP was able to know the priority of the claim, they could theoretically choose option (c) for required claims, and option (a) or (b) for optional claims. However they IdP does not know - the RST does not currently contain that information. Returning a SOAP fault on an optional claim doesn't make sense, and empty values are possibly dangerous, in that a null value could actually be a specified, value-filled variable - in which case the IdP could be returning false information instead of no information.
During this discussion, it was mentioned that addition of priority/ requirement of claims with the RST would be a good recommended change to the existing ISIP protocol.
3) Token Type Equivalence Whose responsibility is it to match equivalent token types? Does the Selector do this or does the IdP have to have all the different token type permutations listed in their cards?
4) 128-bit Key Size What is the community view on 128-bit key sizes? Does anyone even want to play ball here? What is the expected use pattern for a component owner in Sierra Leone, for example? A number of people expressed the need for the ability to refuse to work with such components, but at this time, usage of a 128-bit key is not detectable up-front... another comment was that we'd be better off working to abolish export controls altogether...
Is there a current community consensus on interoperation? Do we need one? Currently, 128-bit key sizes are outside the ISIP spec.
5) Platform-level "default selector" mechanism. What do we have to do to implement a desktop client that can invoke a user-defined default selector? In Windows? On Linux? Can we even do interop tests of rich clients without a selector selection mechanism?
6) Kim suggested that we add a "best practice" line for IdPs that they should accept at least one passwordless authN method.
7) multi-valued claims should be returned in the order they were presented. M$ will put up an IdP that sends multi-valued claims. We have done namespace already; avoid test collisions; will also test an unexpected multi-valued claim. we don't want to change current undertanding on existing claims (i.e. namesspace)
8) Invalid Claim values -- 'empty' is not a special case
9) Ignore padding in token -- do we merge this with whitespace, other residue around the token payload? Should be one test, but the test may test for different 'padding/characters'
10) 3 Condition Handlers for RP's dealing with lack of installation of either a selector and/or a browser extension: installed? selector no yes no browser yes no no
11) RP should react in a way that invites users to start using cards (and a pointer to getting started selecting a card selector, etc.)
12) General usability: To create an extensible, reliable, modular identity ecosystem, the community (and specfiically the leaders driving interoperability) should provide more comprehensive best practices to help develop an underlying consistency to RP sites. These include usability tests and recommendations such as:
13) what to do when logging into something you have never seen before. usability across platforms -- different features, different display, setting best practices -- is the privacy policy displayed? Can we draft a set of usability recommendations - what to do if? Out of this may come a set or Usability recommendations and tests for user-facing components.
Action Items:
- Identify an owner of a KDC who can also issue an information card (this is for kerberos testing). Possible owners: Dale and/or RL Bob
- Mike Jones to check out which parts of requiresAppliesTo are applicable for self-issued vs. managed cards (possibly there is a distinction for web services based RPs vs. web-based RPs)
- Pam to add test cases around non-specification of the token type in the card by the IdP.
- Pam to add a test case around display of standard certificates (cases already exist for display of EV certificates)
- Mike Jones wanted confirmation from the group regarding Assymetric binding to the Identity Provider -- is anyone else using this?
- Pam to add 2 "Rich Client Applications" tests: 1) RP is the end app, equivalent to claims based "Hello World" 2) RP requests token in order to use it in turn for a service
- Uppili to send more information to the list in regards to issues his team has had with CardSpace and holder-of-key not working anymore
- Pam to add new condition handling case where the site name doesn't match the name on the certificate.
- Pam to distinguish in the document between certificate errors on RP cert vs. certificate errors on an IDP cert
- Pam to add a new case where a card import should fail if the cert doesn't validate.
- Pam to add a new case to check that cards who don't provide claims don't show up in the selector.
- Pam to talk to Don Schmidt regarding null values in CardSpace
- Pam to test card import/export across MS Selector Versions
- Pam to alter doc to make the "account creation via self-issued card" and "account creation via managed card" at an IdP one case, not two
- Pam to decouple the term "accepts and creates" in the RP initial Cases.
- Mike: OpenID RPs, IdPs: Should we break up PAPE support? in one case we did (breaking out phishing) we should be consistent.
- Charles took notes. This email only goes to the new user-centric-identity-interop@googlegroups.com; A reference will be sent to OSIS general and the old Barcelona list which wlll be officially closed. The Barcelona wiki will remain up.
- Mike,Charles, Pam - Complete plan by categorizing each test as follows: - do we have a test (yes, which one show pointer) If no, then: - are we building a test? - what order will we build these tests?
Next Milestones:
December 14: Buy-in for the plan achieved among OSIS members and likely participants. December 21: Revised plan produced and published.
|
