[security] passing password on identification request?

Mon Oct 19 18:02:12 UTC 2009

I think Fen is thinking XDI rather than XRI.

XRI is a identifier format and discovery protocol.

XRD is a RDF like data query language that makes use of XRI abstract  
identifiers.
Think an advanced SPARQL with write ability.

XDI has a fine-grained identity based permissioning but still relies  
on oAuth or other PKI based authentication.

John B.

On 2009-10-19, at 2:53 PM, Fen Labalme wrote:

> You might want to look at XRI which is not tied to browsers.  I  
> haven't been working closely with it for a while, but about a year  
> ago we spec'd a way to have shared data repositories with  
> permissioning.  I think the DataPortability folk have been working  
> on this, but since OpenID stole the spotlight from XRI I'm not sure  
> there's much traction in this area yet (but there might be if more  
> people ask these sorts of questions).
>
> One thing I'll say is that the example URL you presented with  
> `&user=USER&pass=PASS` is very insecure for at least two reasons: 1)  
> you never want to have name and password in the same message, as if  
> anyone ever manages to sniff that one line, the user is fully  
> compromised; and 2) requiring the user to share their password with  
> the 3rd party web-service - or even the primary one - is considered  
> dangerous (as John said: "Users giving there passwords to RPs is  
> what openID is trying to prevent.").
>
> If you do want to take a look at XRI, note that what you really want  
> is XDI (XRI Data Interchange) - see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xdi
>
> And to answer you final question, it may be just a matter of time,  
> as pieces of XRI/XDI have been finding their way into OpenID to help  
> solve problems as they come up, and (of course) new solutions are  
> being developed, too.
>
> hth,
> =fen
>
>
> Anthony Brassac wrote:
>>
>> I see, what's unfortunate is that openId was perfect for the needs  
>> of our web application. Unfortunately it won't meet the  
>> requirements of our web service, so we may actually choose to write  
>> our own system now (seeing as how even oAuth needs manual logging  
>> in at some point too). Though I'm surprised that we seem to be the  
>> only ones with this problem, is that a technical challenge to make  
>> openId more web service friendly or is that just a matter of time?
>>
>>
>> On Mon, Oct 19, 2009 at 11:40 AM, John Bradley <ve7jtb at ve7jtb.com>  
>> wrote:
>> The user needs to approve the oAuth access somehow.  It only needs  
>> to be a web browser if you want to use openID for that.
>>
>> Sorry for the bad news, but openID requires a browser at this point.
>>
>> If you are the authenticator for the account and not a third party  
>> then there are lots of ways to solve your problem,  but you will  
>> have to stretch to claim they have any connection to openID.
>>
>> John B.
>>
>> On 2009-10-19, at 12:28 PM, Anthony Brassac wrote:
>>
>>> But no matter what, even with oAuth I will need to log in using a  
>>> web browser at some point in order to get that key/secret  
>>> combination, won't i? Unless there are providers that offer  
>>> programmatic log in?
>>>
>>> I have a feeling we are going to end up having to write something  
>>> ourselves :S
>>>
>>>
>>> On Thu, Oct 15, 2009 at 11:54 AM, John Bradley <ve7jtb at ve7jtb.com>  
>>> wrote:
>>> You can have the user authenticate to the oAuth provider via  
>>> openID if it is a condition of the grant:)
>>>
>>> That may be the best way to do it anyway depending on how the app  
>>> is configured.
>>>
>>> John B.
>>>
>>> On 2009-10-15, at 12:00 PM, Anthony Brassac wrote:
>>>
>>>> Thanks all for your replies, oAuth looks like it could do it for  
>>>> us, however it seems management had agreed upon using OpenID  
>>>> (research grant related I think), so I'll have to see what gives.  
>>>> Anyway, I appreciate your support.
>>>>
>>>> On Wed, Oct 14, 2009 at 1:47 AM, SitG Admin <sysadmin at shadowsinthegarden.com 
>>>> > wrote:
>>>> Users giving there passwords to RPs is what openID is trying to  
>>>> prevent.
>>>> That is why passwords are not supported in the redirect.
>>>>
>>>> Hmm . . . minor clarification here, though: users giving  
>>>> passwords *their passwords for the OP* (or otherwise transmitting  
>>>> "in the clear") is not compatible with OpenID.
>>>>
>>>> If the RP wants to ask for another password (one local to that  
>>>> system), e.g. for rarely invoked high levels of access, it  
>>>> *might* be compatible with OpenID (depends on the exact use, but  
>>>> isn't automatically NOT compatible).
>>>>
>>>> The description Anthony gave sounds vaguely like Kerberos (from  
>>>> the MIT dialogue), but my mind is stuffed full of other things  
>>>> right now and I get a bit of a headache just getting some meaning  
>>>> out of roughly half of it (the rest seems beyond me tonight).
>>>>
>>>> -Shade
>>>>
>>>> _______________________________________________
>>>> security mailing list
>>>> security at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-security
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> security mailing list
>> security at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091019/2d55d069/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091019/2d55d069/attachment-0001.bin>