Re: Documenting implicit assumptions?

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.

> 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?

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

which file? 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).

> 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.

> 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.

>> 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?

> 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 (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.

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).



Received on Monday, 31 January 2011 16:54:48 UTC