Re: [W3C Web Security IG] developers security check list

On 7 September 2016 at 01:18, Bil Corry <bil@corry.biz> wrote:

> 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.
>

I think there are two fallacies here.

1. Where in the document does it say that the IDs are 'internal' IDs.  Why
would that matter anyway,
2. why do you feel is it in appropriate?  I use WebID's for internal and
external identifiers all the time.

The advantage of an HTTP URI over a number is that it is both unique and
dereferencable.  This is web 101.

I certainly agree that for external identifiers it's a good idea if the use
case supports it.  Id argue that the use case always supports it, because
the web is so big, it benefits from unexpected reuse.


>
>
> - 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 Wednesday, 7 September 2016 00:17:43 UTC