Skip to content

Latest commit

 

History

History
139 lines (101 loc) · 10.5 KB

2021-09-27.md

File metadata and controls

139 lines (101 loc) · 10.5 KB

W3C Solid Community Group: Authentication Panel

Present

Announcements

Meeting Recordings and Transcripts

  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Use panel chat and repository. Queue in call to talk.

Participation and Code of Conduct

Scribe Selection

  • Sarven

Introductions

  • name: text

Topics

Public OIDC Client URI

URL: solid/solid-oidc#40

  • AC: There are different flows (implicit, auth code flow, hybrid flow; help people move from implicit to auth flow). when a client identifies itself.. added publiv oidc client uri as a way for apps that don't have their ids. allows clients avoid dyanmic.. and to start with uri. why not just create a client id? the fact that they don't - concerns about what is allowed and do. open question: can we just remove this? would anyone like more info on this?
  • SC: where do emphemeral ids fit?
  • AC: dynamic flow covers this already. it'll be around.
  • ME: In order to log in CSS, would the auth code flow be required ?
  • AC: orthogonal to auth code flow. it is already part of this regardless . i use auth code flow / metaphor to understand this particular future. this is just about.. emphemeral clients.. in principle use auth code flow. should they give out a URI? we heard from CSS that it is problematic to implement. has much more security c.. then dynamic registeration process. typical for emphemeral client.
  • eP: re dunamic client registration: we rely client id.. for specific auth. for against removing. how do you see dynamic reg. playing a role? we still have iri to identify the client.. just in the scope of the idp.
  • AC: this is where authn/z come into play.. and interacting. this has been the direction for this panel for awhile.. you may very well have a need for .. in the authz layer may want indicating 'everyone'. on the authn layer.. i don't see much use for (anonymous?) (
  • eP: DCR is optional, but with the public IRI, it becomes unnecessary.
  • AC: dynamic .. when client doenst have an id. i'd hope / forsee, all clients have a registration somewhere... During development, not necessarily public, which is when having an ephemeral ID would be useful.
  • eP: what could be said as a client id in that case? currently in the access control .. which id? local id?
  • AC: local id. eg. uuid, or something else. if emphemeral, it is going to be different at every run... and authz system is probably not going to allow you in in that case.
  • eP: defaults should be that client has no access unless granted - constrained? and explictly unconstrain it.. for you
  • AC: I am +1 to removing it. can we have a proposal?
  • SC: Why wouldn't you want the ephemeral client ids be a class or ids that are public
  • ...: WAC has foaf:Agent as public agent
  • AC: That's where distinction is meaningful btw AuthN and AuthZ. Having an IRI to stipulate a class of clients is valuable in the context of AuthZ, but may be problematic for AuthN.
  • ...: I had case in my implementation that I have 2 apps without public webids. With client identifier you just need to approve it once. OIDC has the approval screen so you don't just go through the consent screen automatically. If 2 clients use that generic identifier (Public OIDC Client URI), once you approved the first one, the second one will not get the approval screen and will be approved since first one was.
  • ...: One could make special case for that identifier.
  • SC: What is the property referring to that identifier. Issue seems to be using the same id by different parties. Framing it as single thing it doesn't make sense, but framing it as class might work.
  • AC: For authentication it would be just a thing. I see why authorization might want to refer to it as class/group of things.
  • SC: Isn't it an issue to use a class in the role of an individual in the context of AuthN ?
  • AC: There is a semantic issue, but if we are to remove this concept for the AuthN spec anyway, we don't really need to address it.
  • ...: The current state of the spec weakens the security model of OIDC, which is why the proposal is to remove the notion of a public IRI altogether from AuthN.
  • eP: We want to support redirect-less clients, but we should emphasize that the security model of OIDC is really based on the redirect URL being under the control of the client.

PROPOSAL: Remove the Public OIDC Client URI as a mechanism for ephemeral clients to login to a Solid-OIDC identity provider.

  • NAS: +1
  • eP: +1
  • SC: +1 (as far as i understand)
  • AC: +1

ACTION: AC will PR to make this particular change.

Required scope for webid claim

URL: solid/solid-oidc#29

  • AC: (for background) In OpenID, scopes are what define what appears in the ID token claims. There are predefined scopes (e.g. openid, profile, email, phone, offline...). historically/currently in solid, we arbitrarily added webid claim to access and id tokens. that's sort of .. not really following best practice of oidc. if we introduce a new claim (ie. webid) it should have a corresponding scope to indicate what claims the client wants to retrieve.. one option: for the webid claim to appear.. use webid scope or sometihng similar. questions/comments?
  • ME: scope seems like visibility?
  • AC: in oop scope definitely has visibility.. in context of oidc, also visibility but really about whether or not.. an idp releases certain claims into id token.. whether client that's about to receive this token.. is able to know these tihngs.. email, phone number.. where you login through a provider.. this app wants to know a list of htings.. phone etc.. and you can say yes/no. should there be a mechanism where we identify by scope.
  • eP: if we have webid.. breaking it into apart.. first adding webid scope. to get the webid claim. but i wouldn't block one for the other. go step by step.
  • AC: re change to solid.. whether webid should be alone or osmetihng else..
  • NAS: originally in solid authz lib, the webid scope was added.. the idp did include webid claim into id token without the scoping present.. more of an nss behaviour rather than a spec behaviour. lets make this clear in the spec because it is idiomatic to openid.
  • SC: Perhaps consider whether the proposal is for ~FPWD or long term..
  • AC: actually explicit scope in the request can make easier to change what claim is being returned in the id_token

PROPOSAL: For ID tokens that release the webid claim, a client must provide a webid scope

  • eP: +1
  • NAS: +1
  • AC: +1
  • SC : +1

ACTION: AC to PR

State of the Solid-OIDC Primer

URL: https://github.com/solid/solid-oidc/issues?q=is%3Aopen+is%3Aissue+label%3Aprimer

  • AC: The primer is out of date, and should be brought back up-to-date with the current state of the spec draft. The images should be made consistent with the spec for instance.

ACTION: eP will review Primer. Ping current authors/editors for status update.

Plans for a test suite (RP, RS & OP)

URL: solid/solid-oidc#22

  • AC: we need test as we near CR. It may be unreasonable for Pete ot writ test suites for every panel... more realistically, editors of a spec to produce a test suite. that means the test suite has to come out of this panel. we may need to do initial work ourselves. that invovles: 1) relying party side, 2) oidc provider side 3) resource server side. the strategy for each will be slightly different. for some we may mock things.. to test relying party for interactions.. anyone has further thoughts on this? how about a general plan?
  • eP: what kind of test would be useful NAS?
  • NAS: 1) for lib developer.. that oidc provider is spec conformant.. 2) to test the RP: not sure. it'll involve mocking.. mock rp and rs.. to make sure values returned by op t... DPOP header is set properly.. that'd be helpful for devs 3)
  • eP: test suite.. language agnostic. especially clients wil have biggest diversity of ... from the panel: can't be lang specific. hard to see. we could provide compliant op and rp. client can implement.. runs it against those endpoints. not sure still hwo to have a generic test.
  • SC: probably we should invite Pete and coordinate it with him.
  • AC: sounds alright to invite..

ACTION: AC will ping solid/test-suite and invite to a meeting to revisit this topic.

WWW-Authenticate header

URL: solid/solid-oidc#25

  • eP: it doesn't say which parapmeters.. we should specify that. don't have a proposal. but shouldn't leave it unspecified. anyone has a clear idea?
  • AC: a number of other specs defines their own need e.g DPOP.. IRRC, algorithm, space for support algs.. UMA has its own set of requirements.. if RS is UMA based, .. surely there are others. we're both clear enough and not overly prescriptive.. because of other authz systems are in use.
  • AC: the minimal set may be DPOP.. but knowing explictly what that is will help implementers.
  • eP: Since only client interacts with RS. IDP only serves public keys.. Nick, would you like to see..
  • NAS: we do discover RS from the WebID document.. basically discover webid from id tpolken.. and festch resources from RS.. as of now, access token from ... if that would fail and www-authenticate header back.. client will proceed with the field-value.
  • ep: What do yo ucheck in the header?
  • NAS: depending on authn methods are supported.. e.g. UMA is used by RS, if also supported by clients.. but that's going ot be.. a list of methods supported by ecah client
  • ep: do you check anything in header in the 401 response
  • nas: we don't inspect www-authenticate

ACTION: eP will look into and provide feedback in issue.. what can possibly go in the HTTP header.