[OpenID board] Fwd: [OIDFSC] Specs council status and work - POSSIBLE CALL TODAY

David Recordon recordond at gmail.com
Sat Jun 5 02:49:23 UTC 2010


Given that it's Friday at 8pm, I'll do my best to answer Dick's questions.
Dick's assertion that the proposed Connect work group charter, "is vague,
wide ranging and heavily overlaps other working groups" certainly applies to
the v.Next proposals as well.

The first sentence of the charter clearly states that the work group will
be, "complementing other active OpenID Foundation Working Groups." If the
Discovery work group becomes active and produces useful technology, it would
certainly be adopted! To date no one in the OpenID Foundation has done
technical work on discovery since OpenID 2.0 was finalized. It's thus
reasonable for it to be in scope and later abandoned if all works out. If it
is removed from the scope and the Discovery work group doesn't produce a
working proposal, this work group 1) couldn't discuss discovery and 2) would
have to be fully rechartered in order to work on discovery.

The goal of the charter is to help frame the problem the working group is
going to solve; not answer all of the questions about how it will happen
before the work group is even created.

--David


On Fri, Jun 4, 2010 at 6:53 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  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.
>
>
>
>                                                             Thanks,
>
>                                                             -- Mike
>
>
>
> *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.
>
>
>
> -- Dick
>
>
>
> Begin forwarded message:
>
>
>
>  *From: *Dick Hardt <dick.hardt at gmail.com>
>
> *Date: *June 4, 2010 6:37:46 PM PDT
>
> *To: *Martin Atkins <mart at degeneration.co.uk>
>
> *Cc: *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
>
>  withdrawn.
>
>
>
>
> 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.
>
>
>
> -- Dick
>
>
>
>
>
>  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
>
>  Working Groups.
>
>
>
> What will the protocol do? Will it do everything that OpenID 2.0 does? Is
> is a replacement for OpenID 2.0?
>
>
>
>
>
>  3) Scope:
>
>  - 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
>
>  never reassigned
>
>
>
> 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
>
>  extension
>
>
>
> 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
>
>  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 and other emerging 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
>
>
>
>  ·       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
>
>  specifications.
>
>
>
>  ·       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
>
>  statement.
>
>
>
>
>
> _______________________________________________
> board mailing list
> board at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-board
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20100604/434b3c45/attachment-0001.html>


More information about the board mailing list