Difference between revisions of "How to make a better OpenID IDP for RPs"

From IIW
Jump to: navigation, search
(Undo revision 3263 by Igiwydijok (Talk))
 
Line 1: Line 1:
=[http://ipelasuq.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
 
 
Session: Day – Number - Space Location Wednesday – Session  - A
 
Session: Day – Number - Space Location Wednesday – Session  - A
  

Latest revision as of 14:11, 2 February 2011

Session: Day – Number - Space Location Wednesday – Session - A

Convener: Erich Sachs

Notes-taker(s): Breno de Medeiros

A. Tags for the session - technology discussed/ideas considered:


   Usability, Certification, Industry Standards


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


1. Support PAPE request for

    a. ICAM profile
    b. Password protection

2. 99.5% Uptime 3. No-preregistration, i.e., SMTP 4. Support discovery (directed identity, webfinger) 5. AX for 'email' and _always_ return it 6. Only return email address you receive via SMTP 7. URL = global, non-recycled, unchanging 8. 1-page consent flow 9. Default to no re-auth on consent page 10. Default auto-approve future-logins to RP 11. Support checkid_immediate 12. Support PAPE max_auth_age = 0 (password re-prompt, password protection) 13. Auto-detect mobile, non-JS browsers, and show friendly consent page 14. Tell certifier the optional features you support

-- Question: What are the features a new IDP should support?

Q: How do I know that a new IDP supports a security profile? A: Checks against OIX white-list.

Q: This is not exactly ICAM certification, what it means to be certified regarding these practices? A: Define a variant of the ICAM profile with a usability focus, release it to Kantara to develop a unified certification program.

- Password protection: There is a document formulated to replace NIST requirements with a 'password attack resistant profile' that defines levels of protection against online password guessing attacks.

- What about uptime? How do we measure/certify this?

- No pre-registration: Google would like to preserve the initial spirit of OpenID, not require contracts with other parties, substitute it with a certification program. Q: How to deal with liability? A: Look at email-based password recovery, no liability today. Use risk management rather than rely on contracts and liability provisions.

- Deal with discovery. Is Webfinger too complicated? What about 3rd-party email addresses that Google hosts? Does host-meta suffice?

- Email address: Needed for business reasons, costumer requests. There was initial variance on whether the same information every time (with explicit approval or auto-approval). Additionally, if email is required, should not allow user to opt-out of logging in without the email.

- URL types. Realm flexibility (moving hosting location). They actually want to suppress consent page re-prompt for the same realm, and the concept of ream doesn't break down along hosts/domains.

- 1 Page consent flow for minimal information (email): Lawyers can make this very scary. How do you certify this? Discussion on user's expectations of behavior -- if user chose IDP for paranoia, this would be acceptable to RPs. But if the user expects good usability (overwhelming majority) the RP wants the OP to meet this expectation.

- Discussion on standardize on AX/SREG/standard set of attributes.