[OpenID board] Fwd: [OIDFSC] Specs council status and work - POSSIBLE CALL TODAY
Michael.Jones at microsoft.com
Sat Jun 5 01:53:16 UTC 2010
Per a thread on the specs council list, while I'm not opposed to a Connect working group, I do agree with Dick that we'd all probably be better off, if the Connect proposers were to answer Dick's questions intended to clarify the charter and how this work is intended to relate to other work, which he posed a while back. Could the proposers do that? It would go a long way towards keeping us all in sync.
From: openid-board-bounces at lists.openid.net [mailto:openid-board-bounces at lists.openid.net] On Behalf Of Dick Hardt
Sent: Friday, June 04, 2010 6:40 PM
To: OpenID Board (public)
Subject: [OpenID board] Fwd: [OIDFSC] Specs council status and work - POSSIBLE CALL TODAY
Per my reasons outlined below, I do not think the Connect Charter is appropriate for the OIDF.
With a narrowed scope and clearly language (which is likely what most people think it is) -- I would support this WG Charter.
Begin forwarded message:
From: Dick Hardt <dick.hardt at gmail.com<mailto:dick.hardt at gmail.com>>
Date: June 4, 2010 6:37:46 PM PDT
To: Martin Atkins <mart at degeneration.co.uk<mailto:mart at degeneration.co.uk>>
Cc: openid-specs-council at lists.openid.net<mailto:openid-specs-council at lists.openid.net>
Subject: Re: [OIDFSC] Specs council status and work - POSSIBLE CALL TODAY
On 2010-06-04, at 12:03 PM, Martin Atkins wrote:
On 06/04/2010 11:52 AM, Dick Hardt wrote:
I asked a number of questions about Connect that I have not yet seen
responses to. I think the issues need to be addressed or the proposal
Does this mean you wish to reject the proposal on the grounds of reason (a) in the process document?:
"an incomplete Proposal (i.e., failure to comply with section 4.1)"
If so, it would be useful to know precisely which of the line items in section 4.1 you think are lacking so that the proposal can be revised effectively.
>From some of your comments in the thread on the specs list, I guess you might instead be rejecting it on the grounds of reason (b):
"a determination that the proposal contravenes the OpenID community's purpose"
If that is the case, I would be interested to hear in what you believe the OpenID community's purpose to be in this context and how the Connect proposal deviates from it.
4.1 (a) and (b)
4.1(a) Incomplete: I emailed David asking for a number of clarifications on the scope and purpose. (I will forward that email to the list after I send this one for easy reference)
I have inserted other questions in the draft charter below.
4.1(b) The current mission of the OpenID Foundation as voted on two meetings ago was to solve the internet identity problem by building on top of OpenID technology. The stated purpose of Connect is "building on top of OAuth 2.0 ". While this may be the right thing to do, it contravenes the OIDF Foundation's stated mission.
Additionally, the Connect WG overlaps with the Discovery, Core and User Experience WGs. It is the purpose of the Foundation to bring the community together to solve the issues together.
There are a number of aspects to Connect that are unique. If the scope is tightened up, the purpose clear, and it is described how this WG works with the other WGs, then we can move forward with this charter. For example, rather than doing discovery in this WG, Connect should defer discovery to the Discovery WG.
As it is, this charter is vague, wide ranging and heavily overlaps other working groups.
1) Working Group name: Connect
2) Purpose: Develop a version of the OpenID protocol optimized for use
on the web by building on top of OAuth 2.0 and discovery technologies
such as host-meta while complementing other active OpenID Foundation
What will the protocol do? Will it do everything that OpenID 2.0 does? Is is a replacement for OpenID 2.0?
- Explore building on top of OAuth 2.0
(http://wiki.oauth.net/OAuth-2.0) from the IETF for the user
authorization flows and extension mechanism
Is the WG going to explore OAuth 2.0 or build on top of it per the pupose?
- Explore using the Web Host Metadata specification
(http://tools.ietf.org/html/draft-hammer-hostmeta) and Well Known URIs
(http://tools.ietf.org/html/rfc5785) via SSL for discovery
discovery of what? this is vague -- see explicit discovery capabilities in the Discovery WG. Why is this done in Connect and not just use the output of the Discovery WG?
- Explore the ability for a rich client (such as a browser) to
discover and interact with the website on the user's behalf
I don't know what this means specifically. Is that not what a browser does today? It looks at the website, discovers things and interacts with it.
- Explore making user identifiers OAuth 2.0 protected resources which
return profile information and links to other API endpoints possibly
using JRD (http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/)
assuming it is submitted to the IETF
Why do you want to explore this?
What is the objective?
What is the JRD reference for?
- Explore the optimal migration path for implementors of OpenID 2.0
Explore or develop? Why the "optimal" adjective? Would this be in a spec? Documented in anyway? Is this a recommendation?
- Explore how the functionality provided by existing OpenID 2.0
extensions could be re-imagined on top of OpenID Connect
All extensions? This seems very broad. What would be the output?
- Explore how the concept of delegation should evolve
delegation of what? what do you mean by evolve? where do you want it to do?
With all these explorations, this seems more like a research project than a standardization effort.
- Support for simultaneously authenticating the user while also
authorizing other OAuth 2.0 protected resources that the server is
able to issue access tokens for
which server? I think I know what you mean, but it is not clear.
- Support users explicitly choosing a server or typing in a variety
of URLs and email addresses for discovery
user typing in where? discovery of what?
what are you trying to solve. This again seems prescriptive of how it will work rather than describing scope. Is it a goal?
- Separate the user identifier from the user's human consumable
profile URL such that it is hosted via HTTPS, globally unique, and
why is this here? Is this a goal?
- Drastically reduce the complexity of discovery
sounds like a goal rather than scope.
- Reduce the complexity of the verification processes possibly by
comparing the subdomain of the user identifier and token endpoint
verification of what? sounds very prescriptive rather than part of scope
- Support optional static verification of the token response via a
signature using symmetric keys
which verification? which token?
- Support user interfaces optimized for a variety of screen sizes,
devices, and languages by learning from the OpenID User Experience
How does this relate to the User Experience WG?
- Support the ability to login to non-web browser applications such
as desktop applications
login is vague -- authenticate? Are there other examples? Would the spec cover how these applications interact with the user?
- Support dynamic registration of clients
registration of what? what is a client in this context?
- Define a standard mechanism and basic set of attributes for servers
to share basic user profile data with clients
Wow. You are going to decide what the basic set of attributes are that are needed by all servers? Pretty broad scope!
- Do not prevent the use of asymmetric keys throughout the protocol
such that it may scale into more security conscious use cases
rephrase to explain what is in scope -- ie., ensure that asymmetric keys can be used in the protocol
WG name: User Experience.
(ii) Purpose: Produce a user experience specification or family of specifications for OpenID 2.x that address the limitations and drawbacks present in the OpenID 2.0 that limit OpenID's applicability, adoption, usability, privacy, and security. Specific goals are:
* produce user experience guidelines for less intrusive authentication user experiences than full-page browser redirect,
* produce user experience guidelines for controlled and uncontrolled release of attributes,
* produce user experience guidelines for use of identities and attributes by non-browser applications,
* produce user experience guidelines for optimized protocol flows combining authentication, attribute release, and resource authorization,
* produce user experience guidelines for use of OpenID on mobile devices,
* seamlessly integrate with and complement the other OpenID 2.x specifications.
Compatibility with OpenID 2.x is an explicit goal for this work.
(iii) Scope: Produce a current generation OpenID user experience specification or specifications, consistent with the purpose statement.
(i) WG name: v.Next Discovery.
(ii) Purpose: Produce a discovery specification or family of discovery specifications for OpenID v.Next that address the limitations and drawbacks present in the OpenID 2.0 discovery facilities that limit OpenID's applicability, adoption, usability, privacy, and security. Specific goals are:
* enable discovery for and normalization of OpenID identifiers, including those utilizing e-mail address syntax and those that are URLs,
* enable discovery of features supported by OpenID v.Next OpenID Providers and Relying Parties,
* enable discovery of attributes about OpenID v.Next OPs and RPs, including, but not limited to visual logos and human-readable site names,
* enable discovery supporting a spectrum of clients, including passive clients per current usage, thin active clients, and active clients with OP functionality,
* enable discovery supporting authentication to and use of attributes by non-browser applications,
* enable discovery of public keys,
* enable potential mechanisms for discovering context-relevant OpenID providers,
* 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 discovery specification or specifications, consistent with the purpose statement.
(i) WG name: 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
* enable authentication to and use of attributes by non-browser
* 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 and other emerging devices,
* ensure the use of OpenID on existing browsers with URL length
* 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
* evaluate mechanisms for providing redundancy
* complement OAuth 2.0
* minimize migration effort from OpenID 2.0
* seamlessly integrate with and complement the other OpenID v.Next
* depreciate redundant or unused mechanisms
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the board