<Fabian> p+

<megoth> what is the preferred route forward for the spec?

<megoth> Mitzi: How to we decide on how to decide?

<megoth> Fabian: Could be part of the spec?

<megoth> Mitzi: We could create a WG, the question is the scope of the spec we want the WG to work on

<megoth> ... (Sarven has made a point about having atomic specs)

<megoth> Jackson: currently the spec is a bit unstructured and could learn from how other specs are written (more normative perhaps?)

<megoth> ... (the spec can be a bit confusing today)

<megoth> Fabian: Would prefer things to be well formalized

who is taking notes?

<megoth> Mitzi: How should we work on the current spec?

<megoth> Fabian: We need to define Solid more clearly - that would make it easier to know how to define scope

<megoth> michielbdejong: I'm the scribe

<Fabian> Could we add this to the agenda... https://github.com/o-network/http-copy-symlink

<megoth> (but please help - I'm not good at it)

<megoth> Michiel: Lets look at what is currently implemented and describe that

<megoth> ... (what we want to change is another, separate question)

<Fabian> It was globbing that I was thinking off

<megoth> ... lets not get a situation where we get a spec where the outcome is different from the currents specs

<megoth> ... changes should be another process

<megoth> Fabien: Globbing and TLS might be examples of changes we want to do

<megoth> Fabien: Globbing and TLS might be examples of changes we want to keep

<megoth> (forgot my last line...(

<megoth> Jackson: (Ruben is saying that) we want a more formalized spec

<megoth> ... but we could have it modularized, do not need one super spec

<megoth> Michiel: Two ways of writing a spec: 1) modularized, or 2) all or nothing

<megoth> ... I'm a fan of all or nothing, but you can still have subspecs that are normative

<megoth> ... it's like browsers - browsers work on shared standards, but they still implement it different

<megoth> Mitzi: Tim has said that you should have an all or nothing spec

<megoth> Fabian: All or nothing sounds a bit crazy - it's a lot of features in the current spec, would like to have a more common, lowest denominator

<megoth> Mitzi: The spec should be the bare minimum for interoperability, shouldn't have features in the grey zones

<megoth> ... on the topic of "What is Solid?" - it's about decentralizing power, and to democratize the process

<konobi> Has anyone given consideration to the decision management tool loomio in providing some structured space for these discussions?

<megoth> Jackson, could you write down your point? I didn't get it...

<megoth> Michiel: We're currently writing a pod server, and implementing that against the spec

<megoth> ... we should clarify the what should be in the spec (e.g. WebID-TLS might be good for login, but maybe not for authenticating against all resources)

<megoth> ... Core spec indicates there being specs that extends the core spec

<megoth> Fabian: WebID-OIDC might be good when agents are users, but WebID-TLS might be more suitable for machine to machine interactions

<jackson> I was wondering if webid-oidc is required for Solid, or if you can have some standard for providing tokens and then webid-oidc is a separate standard for generating those tokens

<konobi> megoth: it depends what metadata you're wanting to sidechannel

<megoth> Fabian: I'm against OIDC being required auth-method

<megoth> ... (will implement it if necessary, but want to avoid it)

<Fabian> @konobi are you in NZ as well?

<bblfish> hi

<megoth> Mitzi: konobi, could you tell about a governance model you've talked about earlier?

<Vincent> Hi bblfish :) There's a bot (Zakim) that keeps track of the speaker queue, so if you want to say something, send the message "q+" to be added to that.

<megoth> konobi: (telling about a co-op solution) - in the end it's about defining stake holders, what you want to get in, and what you want to get out

The tool discussed is https://www.loomio.org/

<megoth> thx michielbdejong

i'll take over as scribe from megoth

ah ok. jackson, you go :)

i'll scribe during discussion of jackson's PRs

bblfish: i came in a bit late, sorry
... there was also webid-rsa

<Fabian> HTTP Signatures (With RSA) is my vote

<jackson> henry: On authentication there was webId RSA. Seemed to be an elegant solution

it seemed like an elegant solution

just signs the http headers

would be interesting to compare

does anyone have a UML diagram of how webid-oidc works

so we can compare efficiency etc?

megoth: yes, that's my impression it would be good to have a core specification

that every implementer has to implement

<jackson> Arne: it would be good to have webid rsa as a core implementation

to make sure all pod servers are interoperable

the auth should be part fo the core spec

but exactly which one, should be an open question for a workgroup to decide

Scott: I think there's a couple of tyhings where there can often be confusion

<jackson> scott: We tend ot overuse ssl

we tend to overuse ssl

trying to split it out into what the extensions to transport provide you

secure comms

the possibiltiy for those to be associated with an id

verification

but those three things can happen independently

of just that transport

<jackson> scott: Split up the spec into: secure communications, possibility for secure communcations to be associated with an id that you keep hold of

if i want to use SSTP, my ability to use some of the things that do not fit the TCP/IP, so it will do the secure layer for me

<bblfish> Here is the spec for WebID-RSA https://github.com/solid/solid/blob/master/proposals/auth-webid-rsa.md. I think one can make this more standard and build on HTTP-Signatures, but it is really nice, and fits in with WebID.

but if i'm assigning identification to the session tied to TCP/IP, i'm bound as an implementer

if i can keep them separate, as to where and why they are used, that's better.

<bblfish> WebID-RSA works at the HTTP layer, which is why it is actually better than TLS 1.3 (there may be changes along the way in newer versions)

but the ssl session doesn't need to be the only place where identity and verification are handled

Scott = konobi

Fabian: the place where we authenticate, we terminate it either at the TLS terminator, or elsewhere

i think webid-rsa is like extending a standard for the sake of expanding it, http-signatures is preferable

<bblfish> Ah yes, HTTP-Signatures is much better. I have implemented that with this https://github.com/read-write-web/akka-http-signature

<bblfish> HTTP-Signatures is more worked through, but same philosophy.

webid-rsa adds a user name and changes where certificates are stored

(who?): http-signatures was part of work at Joyent when i was there

i think this is armando speaking

ah no, konobi P:)

<bblfish> So essentially HTTP-Signatures is WebID-RSA but with an IETF standard process. So all one needs is to specify how one ties the WebKey to a WebID.

Mitzi: Jackson's three PRs

jackson: the 3 pull requests

two of them are just deprecating webid-tls in two separate repo's

<Mitzi> Two are about deprecating TLS

that's the controversial thing

<Mitzi> that's the controversial item

webid-tls has not necessarrily been something we've been working with lately

<Mitzi> TLS is not something we have been working with lately in the deployments

it's not in the current major deployments

wqe can open up the discussion for the defenders of webid-tls to amke a point

<Mitzi> We can open up the discussion for the defenders of TLS to give their perspective

client-side tls very poorly implemented in web-browsers

did would be better

you don't need a centralized idp to handle anything

<Mitzi> (Thanks Michiel for scribe work, will stop so we don't double up)

it's not in the spec for the moment, just something that's planned

alternative option: remove webid-tls from all UIs but keep it in as an automated bots to work for

Mitzi: let's record this conversation

and make a table of the decsiion options

we can have a conversation anyway

but we should record the arguments on the github issues

Fabian: but i do want something other than webid-oidc
... if there's a replacement for webid-oidc, that would help me

<jackson> Michiel: IF your server does not support webid oidc you couldn't use it as a pod server

<bblfish> So perhaps we should discuss doing a version of WebID auth using https urls.

<bblfish> ie, to do authentication using HTTP-Signature.

<jackson> Michiel: You could call something a solid-like server, but if it doesn't have webId oidc it will break from a user's perspective

<jackson> Michiel: you could call it a bot pod

Fabian: I think, i don't want to support having to have a login form for a user

i'm happy to support a user passing me a token that does support oidc

if i want an interfaceless server that just support storage, i don't want to support all that other stuff

i don't think it's technically required to support everything

<Mitzi> (Bod pod is a machine used in epidemiology that measures body composition)

we can implement that quite easily once the user's authenticated

jackson: webid-oidc does support flows without user login
... the main reason i would see for webid-tls or alternative is so you can have a system where you don't need any type of centralized idp

webid-oidc does support a flow where you just use codes

bblfish: i would be quite happy to work with people who want to do a webid flow with http-signatures

i think did's are great becaus they rely on blockchain but clearly that's difficult to deploy

but we just need to work out how you link the keypair to the webid

so it would be very similar to how webid-tls does that

it would wokr really well with http2

<Fabian> key-id can be a URI

it's extremely light-weight

and would work also with WebCrypto

because i've implemented that 4 years ago

<Fabian> https://me.example.com/profile/#cert1

and have clients have their own keys

there's lots of possibilities there, i'm happy to work on that

and then perhaps webid-tls can still be rescued by some browsers, but that would take time, so this would be the better answer

and we can have an architectural comparison with webid-oidc

Mitzi: jackson i hope that was useful, and i'm sure the conversation will continue. please create a table with the various options and their pros and cons

<Fabian> Can we please add my two agenda items to 2 weeks from now

note to Fabian: right, you can definitely implement a storage server without an IDP server, sorry.

<Fabian> Week after

<Fabian> Above :)

note to Fabian: so then your storage server can be combined with an IDP server so the two together form a full "pod server" :)

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/wildly/different/

WARNING: No "Present: ... " found!
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy
        <amy> Present+

No ScribeNick specified.  Guessing ScribeNick: michielbdejong
Inferring Scribes: michielbdejong

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)