[foaf-protocols] Why exponent/modulus

Joe Presbrey presbrey at csail.mit.edu
Sat Sep 18 01:04:48 CEST 2010


The point of setting REMOTE_USER was so that you might also say (in htaccess):

Require <http://webr3.org/nathan#me> <http://presbrey.mit.edu/foaf#presbrey>

Ha, isn't anyone still doing authorization in Apache? From httpd
inclusion standpoint, I figured it best to be more interoperable.

If not, REMOTE_WEBID / REMOTE_ID / WEBID are all fine with me.

--
Joe Presbrey

On Fri, Sep 17, 2010 at 6:58 PM, Nathan <nathan at webr3.org> wrote:
> Joe Presbrey wrote:
>> On Fri, Sep 17, 2010 at 5:29 PM, Nathan <nathan at webr3.org> wrote:
>>> ! indeed, can you quickly confirm what'd be in $SERVER['REMOTE_USER']? -
>>> on first read I thought you meant the certificate in PEM format, on
>>> second read I figured you meant the webid having had full authn done.
>>
>> Environment variables are well known and highly visible to developers
>> of all languages on all platforms. They never require non-core
>> libraries to access and are transparent to work with. Here's the
>> environment style I had proposed:
>>
>> REMOTE_USER=<http://presbrey.mit.edu/foaf#presbrey>
>> REMOTE_USER_NAME="Joe Presbrey"
>> REMOTE_USER_DEPICTION=<http://presbrey.mit.edu/self.jpg>
>> REMOTE_USER_KNOWS[0]=<http://www.w3.org/People/Berners-Lee/card#i>
>> REMOTE_USER_KNOWS[1]=<http://webr3.org/nathan#me>
>> REMOTE_USER_[PREDICATE]=[OBJECT]...
>
> +1, only debate is on the prefix (why not WEBID?) see further down for
> more..
>
>> You can presumably select which predicate+objects of the WebID/subject
>> to extract in .htaccess
>
> .htaccess config sounds nice
>
>>> without an ASN.1 parser then any PHP implementation is dependent on
>>> linux + openssl + shell exec permissions, which rules out a huge
>>> proportion hosts
>>
>> Sorry, I wasn't /this/ familiar with libAuthentication. Agreed.
>> Forking is high-cost and a tough sell to web admins. Not good.
>
> aye, this is my biggest worry wrt webid uptake, and wonder if it's a big
> enough issue to warrant us comparing full base64 DER cert or public key
> rather than the individual exponent/modulus - think it's worth a show of
> hands to see who'd object, or too early/late in the day?
>
>>> likewise, I agree - but many (most) don't have this option sadly.
>>
>>> is there a path to getting mod_authn_webid in to the main apache distro?
>>> this would increase the amount of hosts which can support/offer webid
>>> exponentially.
>>
>> I would love to help with this.
>>
>> Apache 2.3 is in Alpha and to be released soon.
>>
>> Demand / a specification to point to / friends might help make this possible?
>
> certainly the latter two could do it sooner rather than later (I hope),
> don't know anybody myself at apache (working on httpd), maybe the
> RESTful/Stateless side of things might be a +1 to getting it in there too?
>
>>> really like the idea of an abstraction point although may need to take
>>> over or provide another env, REMOTE_USER would be v easy to have
>>> overwritten by something else, and people may want to layer auth by
>>> requesting basic/digest auth as well as a second tier.
>>
>> See my environment stuff up top.
>>
>> In this httpd module model, isn't layering basic/digest/webid supposed
>> to be handled already by the time you get to CGI?
>
> unsure, you can probably answer better than I tbh, however certainly
> basic/digest is often handed right down to the script (like php) to do
> custom auth so figured this may be a set-up people might want, however
> the use-case and possible collision may be marginal. Again though,
> entirely unsure and might be worth doing some tests with other elements
> in the mix to see if REMOTE_USER is safe to use, else expose another env
> [WEBID] together with WEBID_ prefixed vars as per your prefixed examples
> up top :) hopefully a bit of research/testing and a straw poll can sort
> this out.
>
> Best,
>
> Nathan
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>


More information about the foaf-protocols mailing list