- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 28 Mar 2019 09:36:56 +0100
- To: Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Cc: public-solid <public-solid@w3.org>
- Message-ID: <CAKaEYh+g9qm=X54DQtMsJX0G4ERfhcNvPiaObDSL5bB6t5_DBQ@mail.gmail.com>
On Thu, 28 Mar 2019 at 09:34, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On Tue, 26 Mar 2019 at 15:59, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote: > >> All, >> >> In the current node-solid-server implementation, we have some >> functionality >> to verify certain interactions with an email verification, such as the >> deletion of the whole Pod. >> >> I think we should make this more generic, possibly through the Web Access >> Control spec, so that users can specify that certain interactions need >> that >> kind of verification. >> >> That way `DELETE /` (i.e. delete the whole POD) could be governed by e.g. >> an explicit rule in the ACL file to ensure verification. >> >> The code for email verification will need to be in the server anyway, so >> I >> think it makes sense for users to be able to reuse this functionality >> where >> they please. One can also envision other verification mechanisms than >> email. >> > > Do we not do it this way already? Or better question, how do we do it now? > > I've seen email addresses in acls before if I remember correctly. > > Wouldnt you just say that the email URI has a certain operation (in this > case write/control?) on the resource. > > Then the server would authenticate a shared secret with an email address > -- not terribly secure, but I think that can be done with a one time > token? > > Is this last part the bit that would benefit from standardization? > Addendum tho this. So many systems I use these days authenticate via a PIN code in mobile. Say 4/6/8 digits. Could the same idea be extended to mobile and tel: logins? Basically there wouldnt need to be anything new in the spec from what I see, but the server would learn to authenticate more URIs. > > >> >> Kjetil >> >>
Received on Thursday, 28 March 2019 08:37:29 UTC