<trackbot> Date: 16 November 2012

<bblfish> which client are you using?

use sip then: zakim@voip.w3.org

<trueg> I am using linphone on Linux which works nice

<bblfish> we tried doing these conf on Skype but that did not work

ah yes

that was you, trueg

<trueg> deiu: yes

lots of background noise

<trueg> deiu: better now?

same

<trueg> deiu: bg noise gone?

trueg, use "Zakim, unmute me"

Identity Interoperability

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability

<scribe> scribenick: deiu

<scribe> scribe: deiu

<bblfish> Feedback on Identity Interoperability

waiting for bblfish to reconnect

<oberger> the usual waiting tone

<oberger> deiu, scribing is easy, when it's like this ;)

<oberger> ...

<oberger> ...

<oberger> wb bblfish

<kidehen> zakim: kidehen is OpenLink

<oberger> Persona

bblfish: the idea of interoperability wiki is to show how different identity systems using different protocols can prove the relation between a string and something, so that one can use multiple authentication methods

<bblfish__> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability#Use_cases_in_Access_Control

bblfish: how we can do this in a way to logically have the systems interoperate
... access control must still work regardless of the authentication method

<bblfish__> mailto:jz@logic.edu

<bblfish__> jz@logic.edu

bblfish: the idea is to have "Principals" (e.g. email principles, openid ones, etc.)

<bblfish__> Principal

<oberger> Principal Principles

<bblfish__> MailtoRef("hjs@bblfish.net")

<bblfish__> = <mailto:hjs@bblfish.net>

<kidehen> denoted

bblfish: MailtoRef("hjs@bblfish.net") = <mailto:hjs@bblfish.net>

<bblfish__> mboxSubj(<mailto:hjs@bblfish.net>)

<oberger> mboxSubj(<mailto:hjs@bblfish.net>) = http://.../foaf.rdf#me ?

<bblfish__> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability#Definition_of_Principal

<bblfish__> Deiu: is wondering if this is relevant to WebID definition

<kidehen> +1

<kidehen> there's less concern about that

<oberger> mboxSubj(<mailto:hjs@bblfish.net>) = <http://.../foaf.rdf#me> ?

<kidehen> the main issue is the definition

<kidehen> bblfish__: I think we are mostly in agreement about the decoupling. It's the definition where we are challenged

bblfish: decoupling is important

<oberger> s/thiks/thinks/

WebID Definition

http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition

<kidehen> I've added my definition to the bottom

<kidehen> Generic URI definition

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition#Generic_URI

bblfish: can remove Robot

<oberger> bblfish: or replace Robor by Software Agent (re. kidehen's argument)

<kidehen> yes

bblfish: you have to have the WebID in that document

<kidehen> yes, but it gets longer

<kidehen> I can tweak it

<kidehen> give some seconds

<kidehen> no

<kidehen> read on

<kidehen> I did

<kidehen> let me check

<kidehen> it was to do with dereference

<kidehen> let me read it again

<oberger> dwdiff | aha actually

<oberger> http://noone.org/blog/English/Computer/Debian/CoolTools/dwdiff.html

bblfish: looking at the generic one, we see that we have a problem with over-generalization
... TimBL argued we need to simplify the definition/spec
... so that we can push this into a standard process (WG)
... there is a strong notion that WebID is "something on the Web", meaning we should push for HTTP(S)

<MacTed> kidehen - your call dropped

<kidehen> calling back

bblfish: it's a terminology problem

MacTed: the narrowing of the spec should not be an elimination of specific stuff, but an encouragement of the narrow spec
... overusing MUST is problematic

bblfish: it is useful to have RDFa and Turtle

<oberger> SHOULD

MacTed: why reduce it down to HTTP?

<oberger> +1 MacTed

<kidehen> +1

-1

<kidehen> URIs == mega inherently interoperable

<oberger> the specs and the primer will be different in this respect : the specs says SHOULD support HTTP(s) URL and the primer only gives examples with HTTP for the moment

<kidehen> HTML is a bad example

No it's not

<oberger> deiu, scribing ? ;)

<kidehen> HTML is bad because it is irrelevant

<oberger> deiu, no worry

MacTed: the WebID must be a URI, regardless of the scheme
... it's a big issue to force HTTP with a MUST in the definition

<oberger> SHOULD use HTTP(s),

<oberger> MUST be dereferenceable

<kidehen> Webfinger for acct:

<kidehen> de-reference == lookup

<kidehen> see TimBL's own docs

<oberger> HTTP GET ?

<kidehen> re. Web Design

<kidehen> de-reference is to lookup

<oberger> you send a mail and wait for a response

<oberger> kidehen: web scale verifiable identity

<oberger> ... in a conceptual document

<bblfish> http://www.w3.org/wiki/WebID

<oberger> ... then an implmentation guideline

<bblfish> http://www.w3.org/wiki/WebID

<timbl> losing henry

<oberger> bblfish, we can't hear ya anymore

<bblfish> ok I'll get back

<kidehen> bblfish: we should make that a formal conceptual guide, something that's referred to from the technical specs

<bblfish> Did I see timbl online

<bblfish> ?

<oberger> ouch

back

<oberger> deiu, you mean ;)

<trueg> it's understandable, phones are a rather new technology

<trueg> :P

<timbl> Sorry bbl fish our fault the feedack

<oberger> kidehen: we have a conceptual guide

<oberger> ... we should connect it to ???

<oberger> anyone for scribing ?

<oberger> I think we should vote ;)

<oberger> acking deiu ?

<kidehen> no, hash URL

<oberger> kidehen and macted's argument vs bblfish's

<kidehen> acct:, ldap:

<betehess_laptop> scribenick: betehess_laptop

<kidehen> ldap: owns the enterprise

<deiu> bblfish: by having a general conception of URI, we can open WebID to other groups

bblfish: kingsley does not want to force people to use http url, because we could loose other communities

<kidehen> timbl: +1 re. goals

timbl: it's about interoperatibility
... but you have to say what the protocol will be for eacxh of those
... what people agreed in Lyon is authentication is different
... but for WebID, it has to stick with the Web

<oberger> so the compliance is on software re. the protocol and not about the WebID identity purely

timbl: you can still have other authentication scheme in the future

<kidehen> timbl: okay, if the "Web" part == http: then that's fine, but the type of HTTP URI doesn't have to be #

<deiu> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition

<kidehen> timbl: since HTTP URI works fine thereby leaving the option for hash or hashless HTTP URIs, as per Linked Data principles

bblfish: you can find all the current definitions at the pasted URI

<deiu> bblfish: people were getting upset about the current definition

<deiu> ... everyone agrees to remove the public key part

I can't even find the definitio0n from TPAC

<kidehen> bblfish: +1

<deiu> ... then we can have a general conception without tying into TLS

<kidehen> bblfish: your interop doc covers the matter, fine.

<deiu> ... the problems is not to make it too general

[bblfish commenting on the definitions]

<oberger> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition#Minimal_http.2B.23uri

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition#Minimal_http.2B.23uri

<deiu> timbl: people agreed at TPAC to go for hash URIs, to make it easy to use on the web

<deiu> ... it's important to be able to have a minimal WebID profile (pseudonyms)

<deiu> MacTed: what came out of TPAC is stuff that only the people in the room agreed with

<bblfish> must be available as Turtle

<bblfish> is that ok?

<oberger> is available == retrievable through HTTP GET ?

<deiu> MacTed: be liberal in what you accept and conservative in what you generate

bblfish, please enforce the queue

<kidehen> not true

<deiu> MacTed, please respect the queue

<kidehen> we've implemented ldap: acct: mailto: http: https: etc.. Also re. http, we have hash and hashless supported

<oberger> discussing a MUST vs a SHOULD.... ah, always the same thing

<kidehen> bblfish: what happens when verifiers fault on our hashless WebIDs? We have 30K+ WebIDs already

<bblfish> Timbl is making a distinction between web architecture document and the protocol document.

<bblfish> the protocol document should be more precise and explain precisely how do do that

<kidehen> Timbl: this is an important point. "Protocol Spec" a technical spec. +1 for your explanation. So you have a conceptual spec and a protocol implementation spec. That spec can be an HTTP based/oriented implemenation spec

<kidehen> timbl: the spec (even if for an HTTP based protocol) has to mesh nicely with Linked Data principles, which then meshes with AWWW.

<timbl> ack

<Zakim> betehess_laptop, you wanted to ask if people have goals to be met by a definition

<deiu> betehess_laptop: we decided at TPAC that WebID has to exist on the web, and we want to make sure that people are not confusing the agent/person with the document describing them

<oberger> should the WebID be a LDP Resource ?

<bblfish> betehess_laptop: what do you make of this definition http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition#Minimal_http.2B.23uri

<deiu> betehess_laptop: we need to have a minimal set of expectation for implementation reasons

<oberger> (hence bouncing the HTTP vs other things to the LDP WG ;)

<kidehen> at this point, let's concede that because of "Web" one assumes a WebID is HTTP URI based

<MacTed> and here we have (again) the difference between "a WebID" and "the WebID Protocol"

<kidehen> MacTed: +1

<oberger> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition#Minimal_http.2B.23uri

<MacTed> feels like "RDF" and "RDF/XML" all over again

<deiu> bblfish: the profile has to say something about the WebID

<deiu> ... the public key doesn't tell anything about the person; it can be replaced by OpenID, OAuth, etc.

"The URI without the hash denotes the WebID Profile. " is not accurate: you don't denote documents

<kidehen> bblfish: you put the public key in description graph (profile document content)

<kidehen> bblfish: +1 uniqueness pursuit in the form of RDF that semantically delivers that

<oberger> So is an OpenID a WebID, betehess_laptop ?

<kidehen> we have three things: WebID, WebID Profile Documents, and WebID Authentication protocol . We can define them clearly

oberger, does it use hash uris? can I get some RDF/Turtle?

oberger, does it use hash uris? can I get *at least* RDF/Turtle?

<oberger> betehess_laptop, most probably not in general ;)

kidehen, that's what we did

<kidehen> betehess_laptop: no you didn't :-)

<kidehen> betehess_laptop: http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition is getting us closer

kidehen, please read the minutes of the TPAC f2f

<kidehen> betehess_laptop: I've read them, stop saying that, please

<kidehen> betehess_laptop: focus on: http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition

well, then you know where we decoupled the concepts and definitions

<MacTed> betehess_laptop - the minutes content doesn't change what the output definition said. and the definition didn't reflect what you are saying here.

and decided to split the specs

<oberger> what's the length of the call in principle ?

MacTed, I'd say that only you and kidehen thing that

<kidehen> betehess_laptop: in http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition, we need WebID, WebID Profile Document, WebID Protocol

kidehen, if the editors of this document didn't reflect what the group decided during TPAC, then there is no value to discus this particular document

<kidehen> betehess_laptop: for a reason, we've already implemented and have hardcore experience with the real problems of interoperability and the enterprise hence ldap: acct: mailtoP etc. .hence the stuff Trueg: demonstrated at TPAC and more

kidehen, the fact that you have an implementation does not mean that as an implementer I'll follow yours...

<kidehen> betehess_laptop: why would you follow my implementation? I am implementing standards.

<deiu> ack

kidehen, and there is no standard re: webid...

<kidehen> betehess_laptop: there are standards for: identifiers, data access protocols, data representation, authentication etc

<bblfish> Todo: Two specs one for WebID and one WebID Auth over TLS

<kidehen> bblfish: +1

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability

kidehen, this meeting is about webid, not webarch

<kidehen> betehess_laptop: you are missing the point of interop. Let's move on

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability#Use_cases_in_Access_Control

kidehen, I prefer to move *forward* instead of in circle. all of this is "deja vu* for me

<kidehen> betehess_laptop: ok.

<oberger> betehess_laptop, you're too old most probably ;)

oberger, must be that :-)

<deiu> Can we set some priorities please?

<kidehen> bblfish: +1 re. that doc

<oberger> or there may be phone call backs (ringing in the back)

<deiu> Please let's focus on setting priorities.

<kidehen> bblfish: we have three definitions to finalize: WebID, WebID Profile Document, WebID Authentication Protocol

<oberger> kidehen, /me think the forst 2 should be in the same spec

<deiu> oberger, +1

during TPAC, we identified that "WebID Authentication Protocol" should actually refer to TLS in order to accept other authentication protocols in the future

<kidehen> bblfish: WebID just resolves to a profile document.

<kidehen> bblfish: the profile document has profile oriented structured content

<oberger> WebID vs URIID

kidehen: I still don't want hash uris

<oberger> MUST for HTTP, and SHOULD for hashed URI

<bblfish> that was alex bertails speaking

<deiu> oberger, +1 to that

<bblfish> qh yes

<MacTed> except some (Several? all?) flavors of IE...

<bblfish> IT is true that one has to check the URI for a hash before doing any dereferencing it

<bblfish> ( I have to do that all the time )

<Zakim> betehess_laptop, you wanted to ask people about goals and to

<kidehen> WebID verifier is a user agent

<kidehen> it should work like any other HTTP user agent

<kidehen> re. HTTP URIs

<kidehen> maybe

<kidehen> me

<kidehen> HTTP URI may be hash or hashless, that's the standard

<kidehen> curl -IL vs curl -I

<oberger> betehess_laptop, should be spec that a WebID profile MUST be a LDP Resource ?

<deiu> kidehen, yes, but WebID URIs should not be confused with the document URIs

<kidehen> deiu: of course they aren't

<webr3> if WebID Protocol didn't have Profiles, then this would be a non discussion - but because it does, we come down to the old range14,issue-57 arguments of whether to use hash or hashless, time has proven we'll never all agree.

<deiu> yes they are, unless you add the # fragment

<kidehen> deiu: no

<bblfish> betehess_laptop: the 303 makes it impossible to work with ldp because it is difficult to find the document to publish something

oberger, I *personally* believe that it would be a good idea, eventually

<kidehen> timbl: we work with any HTTP URI

<oberger> betehess_laptop, +1 AFA LDP Resources may be sepcified some day ;)

oberger, well, I'm pretty confident that LDP WG will reach Rec at some point :-)

<bblfish> timbl: it is very difficult to track 303's in Firefox, to program on the server side

<kidehen> timbl: yes, it is a major pain, but it also provides great interop

<deiu> oberger, from a logical p.o.v. a WebID profile document will always be an LDPR, as long as it is located in an LDPC

<bblfish> ... on the server side 303 it is easy to program but it is difficult for the users to understand and get on board

<kidehen> timbl: my only concern is that verifiers don't fault on hashless URIs.

<webr3> conference is restricted, can't phone in??

<oberger> deiu, /me wonders if hashed LDP Resources have been discussed anyhow in the LDP WG ;)

<MacTed> SHOULD.

<kidehen> bblfish: -1 re. MUST

<deiu> webr3, you should be able to (though we're overtime)

<MacTed> MUST means that verifiers will fault at that point.

<bblfish> timbl: arguing it should be MUST

deiu: actually, this is not true. because if it's an LDPR, then you explicitly enable Write as well

<MacTed> -1 MUST

<webr3> deiu, ahh that's why, thanks

<kidehen> bblfish: timbl : HTTP URI is fine

<kidehen> bblfish: timbl: the utility is clear

<deiu> betehess_laptop, there's nothing wrong with that, as long as you have ACL enabled for it

<MacTed> SHOULD permits those who *can* handle 303s to do so.

<MacTed> MUST says those who can, can't

<oberger> if the WebID Profile document is a LDP Container, then a contained WebID wouldn't necessarily be a hashed URI... :-/

<kidehen> bblfish: can I explain the concern

<webr3> Who /needs/ a 303 here, are there hundreds of thousands of WebID profiles out there with non hash URIs?

<deiu> oberger, a hash WebID URI is an abstract notation referring to the agent, not to the document

deiu, yes, but still, it raises the expectations. note: as I said earlier, I'm not against that at all as I think that the success of webid goes with the success of LDP

<kidehen> webr3: we have 30K+

<kidehen> webr3: our customers all have WebIDs

<oberger> deiu, yes, but several agents in the family's document makes sense of a LDP Container...

<webr3> kidehen, why did they all get 303 URIs rather than frag ones? (out of interest)

<webr3> for any U, if U dereferences to a document D, and D asserts { U cert:key K }, then U is a WebID denoting some agent - so yes to LDP Container or anything else

<oberger> kidehen, the number of customer shouldn't be an argument

<webr3> kidehen, one customer or 3 million makes no difference, the argeument to consider is why hashless rather than hash uris, if we know why you provided them with hashless, then we can understand why others would need to aswell

<deiu> kidehen, isn't that a design issue with your implementation?

<MacTed> WebID verifiers MUST not fail on hashless, they MAY flag "there may be a performance burden here"

<Zakim> oberger, you wanted to ask whether the Document could be a LDP Container and WebIDs could be contained LDP Resources

<kidehen> deiu: we implemented WebID years ago

<kidehen> deiu: ditto LInked Data solutons

<MacTed> PROPOSED: WebID verifiers MUST not fail on hashless, they MAY flag "there may be a performance burden here"

<oberger> yes I wanted... does anyone have a response ?

<deiu> oberger?

<kidehen> MacTed: +1

<webr3> '' they MAY flag "there may be a performance burden here" ''? how? where? when? mate be moot

<webr3> MUST not fail on hashless makes sense, +1

<oberger> the point is hashed uris may not be contained in a container

<kidehen> WebID and LDP are orthogonal

<oberger> I wanted to ask whether the Document could be a LDP Container and WebIDs could be contained LDP Resources

<oberger> it's too hard by text

<timbl> reboot your phone

<deiu> oberger, open an Issue for that maybe?

must be using Windows

<MacTed> I'd like to get closure on that proposal...

<oberger> we didn't discuss hash URIs for LDP Resources in the LDP F2F AFAIR... and I wonder whether stating that a WebID IS a LDP R can lead us to some contradiction

<kidehen> bblfish: +1 re. action items

MacTed, it's not only about performance

<MacTed> I supposed as this is an informal call, it could be a straw poll.

MacTed, that's actually the least of my problems with 303s

<MacTed> STRAW POLL: WebID verifiers MUST not fail on hashless, they MAY flag "there may be a performance (or other) burden here"

<bblfish> Proposal: put the 303 issue in red in the spec

+1

<bblfish> +1

<deiu> +1

<kidehen> +1

<MacTed> issue: verifiers must not fail on hashless URI; they may flag performance or other burdens

<trackbot> Created ISSUE-69 - Verifiers must not fail on hashless URI; they may flag performance or other burdens ; please complete additional details at http://www.w3.org/2005/Incubator/webid/track/issues/69/edit .

<kidehen> I am +1 for the issue

<kidehen> bblfish: RWW please

<kidehen> bblfish: remember we have RWW-0. timbl: yes re. gravity

<bblfish> Public RWW mailing list

<oberger> JS APIs ;-)

<kidehen> trueg: this is where ODS APIs come in

<bblfish> timbl: we can discuss WebAccessControl on public-rww@w3.org list

<bblfish> ... and API

<oberger> see ya

<kidehen> thanks

<kidehen> bye

<bblfish> bye

<oberger> f*cking empathy voip backend :-(

<MacTed> trackbot, end meeting

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Principles/Principals/g
Succeeded: s/mailot/mailto/
Succeeded: s/MailoRef/MailtoRef/
Succeeded: s/MailoRef/MailtoRef/
Succeeded: s/mailot/mailto/
Succeeded: s/mail/main/
FAILED: s/thiks/thinks/
Succeeded: s/you/your/
Succeeded: s/implemented/implemenation/
Succeeded: s/as/has/
Succeeded: s/LDP C/LDP Container/
Found ScribeNick: deiu
Found Scribe: deiu
Inferring ScribeNick: deiu
Found ScribeNick: betehess_laptop
ScribeNicks: deiu, betehess_laptop
Default Present: bblfish, deiu, +33.9.63.67.aaaa, trueg, oberger, MacTed, kidehen, Timbl, with, betehess
Present: bblfish deiu +33.9.63.67.aaaa trueg oberger MacTed kidehen Timbl with betehess
Found Date: 16 Nov 2012
Guessing minutes URL: http://www.w3.org/2012/11/16-webid-minutes.html
People with action items: