Difference between revisions of "OpenID Certification Profile (W3B) URL:"

From IIW
Jump to: navigation, search
(Undo revision 3295 by Igiwydijok (Talk))
 
Line 1: Line 1:
=[http://elykogit.co.cc Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly]=
 
 
Convener: Eric Sachs
 
Convener: Eric Sachs
 
Notes-taker(s): Eric Sachs
 
Notes-taker(s): Eric Sachs
Line 10: Line 9:
 
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 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.
  
  
Line 34: Line 33:
  
  
• 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
  
  

Latest revision as of 12:27, 7 February 2011

Convener: Eric Sachs Notes-taker(s): Eric Sachs

Tags for the session - technology discussed/ideas considered:


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

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