Download presentation
Presentation is loading. Please wait.
1
Attribute Validation proposal for OpenID AX Spec ____________________________
2
How did we get here? Demand for email validation Why not an email specific solution? o No desire to promote email as an identifier (email recycling, email change) o Strong desire to use email as a discovery start point leading to OP and maybe user, but not as an identifier, claimed or 'local' Email discovery is going to be supported in XRD, but not necessarily be used to derive identifiers (see above) o by itself, discovery-flow only does not provide confidence for "account creation", "password reset" or even "sign-on" Idea: Decouple discovery and validation; validate email as a user attribute o At this point, might as well make it a general validation mechanism ____________________________
3
Attribute Validation New modes for AX validate_request and validate_response o validate_request uses the same elements as store_request o validate_response uses the same elements as fetch_response To allow for mixed validate/fetch, a special URL value to mean attribute_select could be added ____________________________
4
Best effort versus strict validation Should the OP be allowed to return a different value to be asserted than the requested by the RP? E.g.: Email validation flows: account creation and password reset. Different email a reasonable approach for the former, but typically not for the latter. o Option 0 "Assertion": No value in the request, OP returns user's. o Option 1 "Strict": Given a value, OP returns same value or fails. Cons: Feedback from RPs indicate that many would not like to change their UIs to have the user type values (emails) twice and prefer flexibility o Option 2 "Loose": Given a value, OP may return a different one. o Option 3 "Choose": RP specifies preference for Option 1 or 2, OP acts accordingly. o Option 4 "Strict-Choose": RP specifies preference for Option 1 or 2, OP is free to always behave as if "strict" is indicated. ____________________________
5
Trust (Quality of validation) Does the user has access to the email inbox (now)? Email (and more general, attribute) validation? o How long since the email was validated? o Proof-of-inbox-control (e.g., OP=email provider & cookie present) Should we have "annotations" to indicate level of confidence or "freshness" of validation? (i.e., PAPE for AX)? ____________________________
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.