Re: Documenting implicit assumptions?

On 31 Jan 2011, at 17:54, Nathan wrote:

> Henry Story wrote:
>> The WebID protocol currently only requires that the WebID be related to one or more public keys.
> 
> even that isn't required to get the same result, the presence of any token in a profile that you can prove the agent owns will do.

We are trying to build a RESTful protocol that works very cleanly with Web Architecture. That is an absolutely fundamental design assumption.  talk of might "tokens" has the ring of Remote procedure 
calls, XMLRPC, and so on to it.

> 
>> Of course it makes sense to add extra information there to point to other places, to
>> describe the agent somewhat, and so on. 
> 
> in all use-cases? I of course agree that having some kind of profile of information is most useful, but it's not a requirement, and isn't needed for all use cases is it?

That is why I said "it makes sense", not "it has to be in all use cases".

> 
>> I think it is probably a good principle that that file be public, because of the danger otherwise
> 
> which file?

I was thinking of the "Profile Document", as we have called it in the spec.

> all we need is a token to be returned via whatever the dereferencing process is (whether that's public key from HTTP GET or a string in a header returned from HTTP+TLS or many other things).

If you think that placing it in the header has advantages, then please put forward a proposal on that.

> 
>> of creating some form of deadlock, where the Profile Document requires WebID authentication on a WebID that itself first requires authentication. Public keys are designed to be public. 
> 
> or, that could be a useful feature, only allow auth from agents you can auth yourself - four party.

I am not sure the protocol as is makes that impossible. I am not sure what the use case is either.
So I can't comment.

> 
>> Perhaps this is a FAQ, or a HOWTO question. And perhaps we should add a best practices document,
> 
> all of it is up for discussion, the result of those discussions may end up in FAQs, notes or howto docs.
> 
> FOAF+SSL != WebID, if it is then why are any of us here? just call it a standard or a spec and be done with it. WebID is what we'll end up with at the end of this process.

FOAF+SSL was also evolving, just as WebID is. I am just saying that you will find some resistance
for revisiting everything and starting from scratch.

> 
>>> and that's if RDF is returned..?
>> It is RDF that is returned, the spec clearly states that the representation is not mandated
>> as long as one can GRDDL it. See section 2.3
> 
> when did we decide that RDF is returned?

Did you look at section 2.3 of the spec? It mentions that any XML can be used, JSON, N3, and so
on, as long as we have an automatic way of mapping that to RDF triples. Is that a problem. If so
please open a specific thread on it.

> 
>> I think we rather start with what we have that functions, and see what issues that has. I really don't see why we should start form scratch. 
> 
> Why not? we've had a proof of concept with FOAF+SSL, we roughly know the end result we want (auth for client agents, maybe for any agent including server), we have a group of specialists here, we can easily put together a list of all the different approaches then weigh them up and discuss.
> 
> If this is just to put FOAF+SSL, as is, through to rec with a new name of "webid" then I can't see there's much need for any of us to be here.

WebID was never finished or specked out precisely. Good protocols start with real world examples. For example HTML was hacked together by Tim Berners Lee and later, much later, the standardisation process started. Of course the standardisation process started off form where Tim Berners Lee had started off. 
When the Atom working group started working on Atom, they had done a lot of work for years before that on their mailing list. It was because that was felt to have potential that companies thought it worth supporting that effort, and bringing it to the IETF. That then started the work.

> 
> WebID (as in, a potential Web Identity solution) stands at the convergence point of almost every web related technology, group, specification and implementer currently existing, and it's the XGs purpose to identify how as many of those technologies as possible can work together to create an identity solution that's usable by the web population, to identify the constraints needed for any future protocol to work, and to help the related sectors towards the convergence point with a shared vision in mind.

What is the issue you find with the current spec? 

> 
> I'm not saying the end specification won't be just like, or even the same as FOAF+SSL (although I'm quite sure it will differ in some aspects), what I am saying is that I believe it's critical to focus the group suitably, to stop classing the "WebID Protocol" spec that's there as WebID protocol (I'd be happy to see it removed or renamed to FOAF+SSL again), and for us all to leverage the skills and knowledge in the group to get from where we are now to full Web Identity (with related protocol specified and ready for standardization).

Sorry, many of us have spent years working on this. We are not closing doors to all new ideas, but what would be the point to start a discussion from 0 here? What are your issues exactly?

Henry

> 
> Best,
> 
> Nathan

Social Web Architect
http://bblfish.net/

Received on Monday, 31 January 2011 17:20:46 UTC