[OpenID] OpenID from a SemWeb standpoint (was RE:Problems with OpenID and TAG httpRange-14)

[Drummond Reed]

  _____  

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Peter Williams
Sent: Wednesday, March 05, 2008 8:08 AM
Cc: general at openid.net
Subject: Re: [OpenID] Calling OpenID 2.0 editors (was RE:Problems with
OpenID and TAG httpRange-14)

 

I like this topic, if only because I think I finally have enough of a handle
of semweb theory to understand it. I also have enough mental model about the
security controls in an openid infrastructure (woefully under analyzed
academically, particularly in the name/address discovery area) to see the
design intent.

 

On the one hand we are dealing with the core nature of openid discovery and
openid auth - the reliance buy these subprotocols on a resource discovery
protocol (HTTP) that was never intended to play the role that openid puts it
in. "The Web is a specific political experiment in social engineering, dont
mess with our manifesto, OpenIDers!".

 

On the other hand, openid is imposing identity semantics on the internet/web
- and need not be limited to the semantics of bearer protocols. "Its just a
bit pipe, stupid."

 

[=Drummond] I agree, Peter. I think OpenID is adding semantics to HTTP URIs
that do not exist at the HTTP protocol layer.

 

As OpenID is not really leveraging HTTP in its as-designed role: identify
and locate web resources. Openid is certainly not leveraging the use of
HTTPS in its as-designed role: obtain assurance for a secure pipe
terminating at a certified security-endpoint known as "a website->DNS
binding". Doing neigher of those things, what is it doing? An OpenID OP is
really "making a statement about" resources (and one day may even fullfill
its vision to make statements about assurance).

 

[=Drummond] Yes.

 

With little doubt, I the OP can choose to state that this or that redirect
messages (treated as protocol states rather than references to resources) is
an OpenID - a notion that need not be tied to URIs or to the smeantics of
the HTTP service.

 

[=Drummond] +1.

 

As someone said earlier in this thread, an OpenID happens to be a URL, but
that does not mean its a URI - or has URI semantics.

 

[=Drummond] On that one, I have to correct you - a "URL" (Uniform Resource
Locator) is technially an "HTTP URI" (or "HTTPS URI" depending on the
scheme). The term "URL" has actually been deprecated by the W3C. See "URIs,
URLs, and URNs: Clarifications and Recommendations",
http://www.w3.org/TR/uri-clarification/. 

 

In making statements about statements, perhaps OpenID is more semweb in
nature than it realizes.

 

[=Drummond] On that, I very much agree. That's why I'm interested in why
Noah feels that, from an OpenID POV, an HTTP redirect does not translated
into an rdf:sameAs statement.

 

=Drummond 

  _____  

From: Noah Slater
Sent: Wed 3/5/2008 6:01 AM
To: Drummond Reed
Cc: david at sixapart.com; general at openid.net
Subject: Re: [OpenID] Calling OpenID 2.0 editors (was RE: Problems with
OpenID and TAG httpRange-14)

On Tue, Mar 04, 2008 at 07:55:41PM -0800, Drummond Reed wrote:
> I'm not an OpenID editor but I remember that there was a great deal of
> discussion around this and there was a good reason (security as I recall)
> that the final redirect needed to be treated as the claimed identifier.
 
I would love to hear this reasoning because it makes no sense to me at the
moment.
 
> 3) From a SemWeb standpoint, I believe the right answer is that ALL the
> identifiers in the chain - the original identifier, all redirects, and any
> "override" back from the OP - should all be considered synonyms for the
> identified resource. In other words, rdf:sameAs statements.
 
This is incorrect. 303 redirects do not imply rdf:sameAs.
 
--
Noah Slater <http://bytesexual.org/>
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080305/65278bd4/attachment-0002.htm>