oops, sent the last one to DH only, see bellow.
Another goal I would like to see is improving the robustness of protocol deployments through enabling fault tolerant approaches such as transparent failover. My main complaint attempting to use OpenID today is that implementations tend to be rather unreliable. The discovery mechanism needs to say what to do if one particular stage fails. In the current discovery mechanism, deployment of redundant servers does not appreciably improve reliability. If there are two servers and one is down there is only a 50% chance of success, this should be 100%. Goal: Specify failover mechanism to ensure reliability > On 2010-05-24, at 7:53 AM, Phillip Hallam-Baker wrote: > >> Goal: Deprecate redundant or unused mechanism >> >> Given the desire for backwards compatibility, removing stuff from >> openid.vnext is going to be hard. But deprecating features is viable >> and leads to similar beneficial effects in the long term. >> >> The OpenID that gets used is going to be whatever is eventually >> integrated into the baseline browsers. Getting rid of the cruft is >> going to be essential before the browser teams are willing to do that >> in any case. >> >> >> On Sun, May 23, 2010 at 7:11 PM, Dick Hardt <[email protected]> wrote: >>> Agreed. How would you phrase that as a goal? >>> >>> On 2010-05-23, at 3:35 PM, Phillip Hallam-Baker wrote: >>> >>>> We have a lot of goals of the 'extend functionality' type. But a big >>>> problem with the current spec is complexity. >>>> >>>> I think we need simplification in as a goal. I think that it is not >>>> only possible to simplify the spec and achieve the extension goals, I >>>> think it is necessary. >>>> >>>> >>>> On Sun, May 23, 2010 at 6:29 PM, Dick Hardt <[email protected]> wrote: >>>>> Hello All >>>>> Thanks for the feedback to date, below is a revised draft. Changes are: >>>>> - changed use of public key from ensure to evaluate. >>>>> - added goal to evaluate single sign out >>>>> - broke multiple atttibute sources and verification of attributes and >>>>> sources into separate goals >>>>> - added a number of additional proposers (Yes, Shade is in the list as he >>>>> is >>>>> supportive of this WG.) >>>>> I welcome any further feedback or additional requests to be added as a >>>>> proposer. If I receive no significant feedback by EOB tomorrow, I will >>>>> consider the charter bashing done. >>>>> -- Dick >>>>> >>>>> >>>>> (a) Charter. >>>>> >>>>> (i) WG name: OpenID v.Next Core Protocol. >>>>> >>>>> (ii) Purpose: Produce a core protocol specification or >>>>> family of specifications for OpenID v.Next that address the limitations >>>>> and >>>>> drawbacks present in OpenID 2.0 that limit OpenID’s applicability, >>>>> adoption, >>>>> usability, privacy, and security. Specific goals are: >>>>> >>>>> · define core message flows and verification methods, >>>>> >>>>> · enable support for controlled release of attributes, >>>>> >>>>> · enable aggregation of attributes from multiple attribute sources, >>>>> >>>>> · enable attribute sources to provide verified attributes, >>>>> >>>>> · enable the sources of attributes to be verified, >>>>> >>>>> · enable support for a spectrum of clients, including passive >>>>> clients >>>>> per current usage, thin active clients, and active clients with OP >>>>> functionality, >>>>> >>>>> · enable authentication to and use of attributes by non-browser >>>>> applications, >>>>> >>>>> · enable optimized protocol flows combining authentication, >>>>> attribute >>>>> release, and resource authorization, >>>>> >>>>> · define profiles and support features intended to enable OpenID to >>>>> be >>>>> used at levels of assurance higher than NIST SP800-63 v2 level 1 , >>>>> >>>>> · ensure the use of OpenID on mobile devices, >>>>> >>>>> · ensure the use of OpenID on existing browsers with URL length >>>>> restrictions, >>>>> >>>>> · define an extension mechanism for identified capabilities that are >>>>> not in the core specification >>>>> >>>>> · evaluate the use of public key technology to enhance, security, >>>>> scalability and performance, >>>>> >>>>> · evaluate inclusion of single sign out >>>>> >>>>> · complement OAuth 2.0 >>>>> >>>>> · minimize migration effort from OpenID 2.0 >>>>> >>>>> · seamlessly integrate with and complement the other OpenID v.Next >>>>> specifications. >>>>> >>>>> Compatibility with OpenID 2.0 is an explicit non-goal for >>>>> this >>>>> work. >>>>> >>>>> (iii) Scope: Produce a next generation OpenID core >>>>> protocol specification or specifications, consistent with the purpose >>>>> statement. >>>>> >>>>> (iv) Proposed List of Specifications: OpenID v.Next Core >>>>> Protocol and possibly related specifications. >>>>> >>>>> (v) Anticipated audience or users of the work: >>>>> Implementers of OpenID Providers, Relying Parties, Active Clients, and >>>>> non-browser applications utilizing OpenID. >>>>> >>>>> (vi) Language in which the WG will conduct business: >>>>> English. >>>>> >>>>> (vii) Method of work: E-mail discussions on the working >>>>> group mailing list, working group conference calls, and face-to-face >>>>> meetings at the Internet Identity Workshop and OpenID summits. >>>>> >>>>> (viii) Basis for determining when the work of the WG is >>>>> completed: Work will not be deemed to be complete until there is a rough >>>>> consensus that the resulting protocol specification or family of >>>>> specifications fulfills the working group goals. Additional proposed >>>>> changes beyond that initial consensus will be evaluated on the basis of >>>>> whether they increase or decrease consensus within the working group. The >>>>> work will be completed once it is apparent that rough consensus on the >>>>> draft >>>>> has been achieved and there are two working, interoperating >>>>> implementations, >>>>> consistent with the purpose and scope. >>>>> >>>>> (b) Background Information. >>>>> >>>>> (i) Related work being done in other WGs or >>>>> organizations: >>>>> OpenID Authentication 2.0 and related specifications, including Attribute >>>>> Exchange (AX), Contract Exchange (CX), Provider Authentication Policy >>>>> Extension (PAPE), Artifact Binding (AB) and the draft User Interface (UI) >>>>> Extension. OAuth 2.0, SAML 2.0 Core and SAML Authn Context. >>>>> >>>>> (ii) Proposers: >>>>> >>>>> Dick Hardt, [email protected] (chair) >>>>> >>>>> Michael B. Jones, [email protected] >>>>> >>>>> Breno de Medeiros, [email protected] >>>>> >>>>> Ashish Jain, [email protected] >>>>> >>>>> George Fletcher, [email protected] >>>>> >>>>> John Bradley, [email protected] >>>>> >>>>> Nat Sakimura, [email protected] >>>>> >>>>> Shade, [email protected] >>>>> >>>>> >>>>> >>>>> (iii) Anticipated Contributions: None. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> [email protected] >>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>> >>> >> >> >> >> -- >> Website: http://hallambaker.com/ > > -- Website: http://hallambaker.com/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
