Difference between revisions of "Certifying Open ID, IdPs, RP"

From IIW
Jump to: navigation, search
m
 
Line 11: Line 11:
 
'''Trusted Email Profile
'''
 
'''Trusted Email Profile
'''
  
Use case: Many websites with a large installed-base of accounts that login with Email & password would like to become OpenID relying parties.  However they only way to support IDPs who provide a higher success rate then their current approach for both registration and login rates.  Instead of each website identifying those IDPs, they would like a <span class="plainlinks">[http://www.proposable.com <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">proposal software</span>] central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements.  The following profile lists those known requirements.
+
Use case: Many websites with a large installed-base of accounts that login with Email & password would like to become OpenID relying parties.  However they only way to support IDPs who provide a higher success rate then their current approach for both registration and login rates.  Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements.  The following profile lists those known requirements.
 
 
 
The IDP must:
 
The IDP must:
Line 18: Line 18:
 
* use an authentication scheme that is at least as strong as the suggested best practices for the ICAM profile
 
* use an authentication scheme that is at least as strong as the suggested best practices for the ICAM profile
 
* have a historic 99.5% uptime of its authentication and OpenID IDP system
 
* have a historic 99.5% uptime of its authentication and OpenID IDP system
* NOT require the RP to pre-register with the <span class="plainlinks">[http://www.merchantservicesprotectionplan.info/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">Merchant Services Protection Plan</span>] IDP or enter into a legal contract with the IDP to use that IDP API (similar to the model of SMTP)
+
* NOT require the RP to pre-register with the IDP or enter into a legal contract with the IDP to use that IDP API (similar to the model of SMTP)
* support OpenID discovery based on either <span class="plainlinks">[http://erinazar.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">erin azar</span>] the domain name (using directed identity) or an Email address in that domain (using webfinger)
+
* support OpenID discovery based on either the domain name (using directed identity) or an Email address in that domain (using webfinger)
 
* support AX requests for the AX "email" parameter and return that parameter on every request, even if it has not changed
 
* support AX requests for the AX "email" parameter and return that parameter on every request, even if it has not changed
* only return the email address that the logged in <span class="plainlinks">[http://www.facebook.com/pages/Carousel-Day-School-and-Summer-Program/142341952505011 <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">Carousel Day School</span>] account receives over the <span class="plainlinks">[http://www.straitstimes.com/BreakingNews/Singapore/Story/STIStory_681222.html <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">Susan Lim</span>] open Internet via the IDP's SMTP service (and thus is equivalent to traditional email validation)
+
* only return the email address that the logged in account receives over the open Internet via the IDP's SMTP service (and thus is equivalent to traditional email validation)
* return a global, unchanging and non-recycled <span class="plainlinks">[http://www.httpguru.com/tech-sambar/atomic-pr-atomicpr-strengthens-team-with-new-hire/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">Atomic PR</span>] OpenID claimed URL for the account
+
* return a global, unchanging and non-recycled OpenID claimed URL for the account
 
* show at most one page in 99% of the consent flows once the user is authenticated
 
* show at most one page in 99% of the consent flows once the user is authenticated
* default to NOT requiring the user to <span class="plainlinks">[http://www.facebook.com/bsafans <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">Beauty Schools of America Complaints</span>]
+
* default to NOT requiring the user to re-enter their password during the OpenID flow if the user had already been authenticated by the IDP before the OpenID request was made
re-enter their password during the OpenID flow if the user had already been authenticated by the IDP before the OpenID request was made
 
 
* default to auto-approving future logins by a user to the same RP
 
* default to auto-approving future logins by a user to the same RP
 
* support checkid_immediate
 
* support checkid_immediate
 
* support the PAPE openid.pape.max_auth_age parameter, though it can choose to always re-authenticate the user no matter what value is passed in that parameter
 
* support the PAPE openid.pape.max_auth_age parameter, though it can choose to always re-authenticate the user no matter what value is passed in that parameter
 
* auto-detect mobile and non-JS browsers and show consent pages that a friendly for them
 
* auto-detect mobile and non-JS browsers and show consent pages that a friendly for them

Latest revision as of 12:18, 19 January 2012

Session: Wed Session 3 Space B

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

Convener: Eric Sachs

Notes-taker(s): Eric Sachs

Notes:

Trusted Email Profile


Use case: Many websites with a large installed-base of accounts that login with Email & password would like to become OpenID relying parties.  However they only way to support IDPs who provide a higher success rate then their current approach for both registration and login rates.  Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements.  The following profile lists those known requirements. 
 The IDP must:

  • support a PAPE request to indicate that the IDP's assertion should follow this specific certification profile
  • meet all requirements of the GSA OpenID ICAM Profile except the requirement to avoid sending PII to the RP
  • use an authentication scheme that is at least as strong as the suggested best practices for the ICAM profile
  • have a historic 99.5% uptime of its authentication and OpenID IDP system
  • NOT require the RP to pre-register with the IDP or enter into a legal contract with the IDP to use that IDP API (similar to the model of SMTP)
  • support OpenID discovery based on either the domain name (using directed identity) or an Email address in that domain (using webfinger)
  • support AX requests for the AX "email" parameter and return that parameter on every request, even if it has not changed
  • only return the email address that the logged in account receives over the open Internet via the IDP's SMTP service (and thus is equivalent to traditional email validation)
  • return a global, unchanging and non-recycled OpenID claimed URL for the account
  • show at most one page in 99% of the consent flows once the user is authenticated
  • default to NOT requiring the user to re-enter their password during the OpenID flow if the user had already been authenticated by the IDP before the OpenID request was made
  • default to auto-approving future logins by a user to the same RP
  • support checkid_immediate
  • support the PAPE openid.pape.max_auth_age parameter, though it can choose to always re-authenticate the user no matter what value is passed in that parameter
  • auto-detect mobile and non-JS browsers and show consent pages that a friendly for them