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=xdiAnd 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 <[email protected]> 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 :SOn Thu, Oct 15, 2009 at 11:54 AM, John Bradley <[email protected]> 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 <[email protected] > 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 [email protected] http://lists.openid.net/mailman/listinfo/openid-security_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
