Announcing Draft 1 of the DataPortability Technical Blueprint
Paul Jones
In spite of the debate over the naming of this document, I'm releasing the first draft of the DataPortability Technical Blueprint. This document has been co-authored by myself, Josh Patterson and Chris Saad. From the abstract of the document:
The DataPortability Technical Blueprint aims to detail the basic mechanisms for linking a user's identity to their data, along
with the necessary discovery mechanisms. This is achieved by leveraging a number of established identity and discovery
standards, microformats, protocols, and technologies.
OpenID is utilised to provide decentralized identity. OpenID 2.0 Attribute Exchange (AX) is utilised for discovery of user service details.
XRDS/YADIS are utilised to provide the details of the various services a user employs.
The draft is published at
http://groups.google.com/group/dataportability/web/DP_Blueprint_v0_1.html
This is an early first draft of the concept, so comments are welcome to help us refine the concept - both in terms of making it clearer, and making it right!
Paul.
Chris Saad
This is the start of our story telling exercise. Comments welcome.
On Jan 11, 7:11 am, "Paul Jones" <pauljone...@gmail.com> wrote:
> Hi All,
>
> In spite of the debate over the naming of this document, I'm releasing the
> first draft of the DataPortability Technical Blueprint. This document has
> been co-authored by myself, Josh Patterson and Chris Saad. From the abstract
> of the document:
>
> The DataPortability Technical Blueprint aims to detail the basic
> mechanisms for linking a user's identity to their data, along
> with the necessary discovery mechanisms. This is achieved by leveraging a
> number of established identity and discovery
> standards, microformats, protocols, and technologies.
>
> OpenID is utilised to provide decentralized identity. OpenID 2.0 Attribute
> Exchange (AX) is utilised for discovery of user service details.
> XRDS/YADIS are utilised to provide the details of the various services a
> user employs.
>
Danny Ayers
> The DataPortability Technical Blueprint aims to detail the basic
> mechanisms for linking a user's identity to their data, along
> with the necessary discovery mechanisms. This is achieved by leveraging a
> number of established identity and discovery
> standards, microformats, protocols, and technologies.
The effort is appreciated, but seems mighty premature - "the consumer
application MUST utilise OpenID Attribute Exchange" - c'mon, I don't
think there's been remotely near enough discussion to settle on such a
mandatory 'blueprint'.
Maybe what the doc contains is the best approach to the particular
kind of data discovery it describes - but from what I see, there's no
way of telling, not even whether that particular kind of discovery is
a requirement for data portability. Even if it is, given 'invent
nothing', are there not existing approaches/specs? (There are.)
Personally I'd like to see some scenarios and use cases, followed by a
survey of alternate approaches and how they might fulfill what's
needed, before trying to get consensus on any particular solutions.
(I'll be more than happy to contribute to these).
Stepping back even further - do we have a roadmap or even any concrete
goals? What is the decision-making process? How will we know when
we're done?
This group has some influential support and a vague consensus of good
intentions on its side. While I do believe we need to act quickly,
being hasty may disrupt those.
Cheers,
Danny.
--
Chris Saad
starting point.
Now we can debate the merits. Words like 'Must' are used technically -
not dictatorially.
The blueprint is indeed the start of what we are trying to achieve.
Tying OpenID to User Services and then User Data. If you think there
is a better way, or further definition of goals needed - then
contribute them.
As discussed here:
The start of the beginning:
http://groups.google.com/group/dataportability/web/work-to-be-done
The design principles:
http://groups.google.com/group/dataportability-public/web/design-goals
Once again, if something is missing or rings false, then add it or
refine it.
Chris
On Jan 11, 8:50 am, "Danny Ayers" <danny.ay...@gmail.com> wrote:
Danny Ayers
>
> Danny a draft blueprint is only a draft blueprint.
Sure, I appreciate that.
It is a concrete
> starting point.
With respect for the work that's gone into it, I would suggest a draft
spec is not a good place to start, because it's picking a path to go
down before we're even sure where we are.
If it's the right technical approach, to achieve any kind of broad
adoption the groundwork will still have to be done to see how it fits
in with existing technologies and to gain consensus. If it's the wrong
approach, either we waste a lot of time & effort (and possibly
support) arguing it out of the way, or we end up with the wrong
approach.
> Now we can debate the merits. Words like 'Must' are used technically -
> not dictatorially.
I'm familiar with the term from rfc2119, I've been in a few IETF WGs
(still am, technically... :-)
> The blueprint is indeed the start of what we are trying to achieve.
> Tying OpenID to User Services and then User Data. If you think there
> is a better way, or further definition of goals needed - then
> contribute them.
>
> As discussed here:
>
> The start of the beginning:
> http://groups.google.com/group/dataportability/web/work-to-be-done
>
> The design principles:
> http://groups.google.com/group/dataportability-public/web/design-goals
Ok, that's *much* more like it.
Let me give you one concrete reason why. I have a telecon with
colleagues from the uk tomorrow morning. It's on the agenda, so I'll
no doubt be asked:
Q: "what the current status at DataPortability?"
A: "Well, a draft blueprint has just been published describing how to
use OpenId AX/Yadis/XRDS for data discovery"
Q: "interesting...why is that needed?"
A: "...it's a concrete starting point"
Q: "why OpenId AX/Yadis/XRDS?"
A: "er...because that's what's in the blueprint..?"
> Once again, if something is missing or rings false, then add it or
> refine it.
Yep, sure. My grumble isn't (yet ;-) with the specifics of the
proposal - it looks interesting - it's more about the cart being
pushed ahead of the horse. I reckon it'll be more in the group's
interests to wait until a little more groundwork has been done before
publishing blueprints.
Chris Saad
On Jan 11, 10:09 am, "Danny Ayers" <danny.ay...@gmail.com> wrote:
>
>
>
> > Danny a draft blueprint is only a draft blueprint.
>
> Sure, I appreciate that.
>
> It is a concrete
>
> > starting point.
>
> With respect for the work that's gone into it, I would suggest a draft
> spec is not a good place to start, because it's picking a path to go
> down before we're even sure where we are.
>
> If it's the right technical approach, to achieve any kind of broad
> adoption the groundwork will still have to be done to see how it fits
> in with existing technologies and to gain consensus. If it's the wrong
> approach, either we waste a lot of time & effort (and possibly
> support) arguing it out of the way, or we end up with the wrong
> approach.
might look like since everyone is asking 'what are you guys actually
going to do' - I think the blueprint is the first, best deliverable we
can provide as an outcome. The healthy debate is certainly necessary
though and I look forward to having i.
>
> > Now we can debate the merits. Words like 'Must' are used technically -
> > not dictatorially.
>
> I'm familiar with the term from rfc2119, I've been in a few IETF WGs
> (still am, technically... :-)
>
> > The blueprint is indeed the start of what we are trying to achieve.
> > Tying OpenID to User Services and then User Data. If you think there
> > is a better way, or further definition of goals needed - then
> > contribute them.
>
> > As discussed here:
>
> > The start of the beginning:
> >http://groups.google.com/group/dataportability/web/work-to-be-done
>
> > The design principles:
> >http://groups.google.com/group/dataportability-public/web/design-goals
>
> Ok, that's *much* more like it.
already stubbed http://groups.google.com/group/dataportability-public/web
I really want to see more people contribute to them rather than asking
why they are not finished.
>
> Let me give you one concrete reason why. I have a telecon with
> colleagues from the uk tomorrow morning. It's on the agenda, so I'll
> no doubt be asked:
>
> Q: "what the current status at DataPortability?"
> A: "Well, a draft blueprint has just been published describing how to
> use OpenId AX/Yadis/XRDS for data discovery"
> Q: "interesting...why is that needed?"
> A: "...it's a concrete starting point"
> Q: "why OpenId AX/Yadis/XRDS?"
> A: "er...because that's what's in the blueprint..?"
>
> > Once again, if something is missing or rings false, then add it or
> > refine it.
>
> Yep, sure. My grumble isn't (yet ;-) with the specifics of the
> proposal - it looks interesting - it's more about the cart being
> pushed ahead of the horse. I reckon it'll be more in the group's
> interests to wait until a little more groundwork has been done before
> publishing blueprints.
the groundwork locked in.
http://groups.google.com/group/dataportability-public/web
TheSocialNetworker
questions get asked of why OpenID was chosen) to say we will utilize
xx authentication mechanism to attach user data and their identity. I
think the starting block is the end goal and what we are trying to
link, what we technically chose to make the draft will come to
realization shortly.
When we are building our concept diagrams/architectures we leave the
finite out since discussion will grow from any fist instance.
Now before I hear it, yes I am headed over to read and provide input
on both "work to be done" and "design goals"