- From: Bil Corry <bil@corry.biz>
- Date: Tue, 6 Sep 2016 16:18:02 -0700
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-web-security@w3.org" <public-web-security@w3.org>
- Message-ID: <CACdphr6fa+n+PunjKutX9qmFmAM1Eagva9tb2iTN46aGfLBdUg@mail.gmail.com>
The IDs referenced in that document are internal identifiers, which WebID is not appropriate. For external identifiers of people, then maybe, if the use case supports it. - Bil On Tue, Sep 6, 2016 at 9:59 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On 6 September 2016 at 11:25, GALINDO Virginie < > Virginie.Galindo@gemalto.com> wrote: > >> Dear all, >> >> FYI, a github project listing security good practices for development >> (including web dev). >> >> https://github.com/FallibleInc/security-guide-for- >> developers/blob/master/security-checklist.md >> <https://github.com/FallibleInc/security-guide-for-developers/blob/master/security-checklist.md?ref=producthunt> >> > > This one is also curious: > > "For user ids and other ids, use RFC compliant > <http://www.ietf.org/rfc/rfc4122.txt> UUID instead of integers. You can > find an implementation for this for your language on Github." > > Now I can see the advantage of a UUID over a simple number. And of course > there's urn:uuid:<id> > > But why not do it the web way and use a user URI? In fact, the web pro > way and use an HTTP User URI (aka WebID). > > Mention this here as it is the "web" security list :) > > >> Regards, >> >> Virginie >> >> >> ------------------------------ >> This message and any attachments are intended solely for the addressees >> and may contain confidential information. Any unauthorized use or >> disclosure, either whole or partial, is prohibited. >> E-mails are susceptible to alteration. Our company shall not be liable >> for the message if altered, changed or falsified. If you are not the >> intended recipient of this message, please delete it and notify the sender. >> Although all reasonable efforts have been made to keep this transmission >> free from viruses, the sender will not be liable for damages caused by a >> transmitted virus. >> > >
Received on Tuesday, 6 September 2016 23:18:32 UTC