That could work. Very XDI RDF-like approach, i.e., the URL/XRI being
resolved is the Subject, the URL/XRI value of the Type element is the RDF
predicate, and the value of the data sharing:KeyInfo element is the RDF
object (in this case a literal).
=Drummond
-Original Message-
From: Recor
So I'm trying to word this and it seems each extension mentions it
slightly differently. Looking at the following, thoughts are
appreciated.
It is RECOMMENDED that OpenID Provider support of this
extension be advertised within the XRDS document, described in
, when working
Oooh, interesting...
So looking at working draft 10
http://www.oasis-open.org/committees/download.php/17293 it seems that
3.2.5 is most relevant in that it describes
xrd:XRD/xrd:Service/ds:KeyInfo which seems to be where in the schema the
key would want to sit. The only thing is that 3.2.5 is tal
Just FYI, the xmldsig KeyInfo element is already part of the XRD schema
because the XRI Resolution spec uses it in the SAML form of trusted XRI
resolution. And either the SAML form or the HTTPS form of XRI trusted res
can give you the security characteristics in the Key Discovery spec.
That said,
Hey guys,
Was looking at
http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight
and curious why the decision was made to define the
element which contains a link to the RSA key or X.509 certificate versus
embedding the key in the XRDS file?
>From the research I've done tonight,
On 1/3/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
> Our proposal was to have the schemas for OpenID hosted at
> schema.openid.net. Some people expressed concerns about having them
> be on openid.net.
>
> Do you have any suggestions? Anyone else have an opinion? Does anyone
> care? ;-)
Being part of
I like this idea of using 307, though haven't thought through all the
repercussions of doing so.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Thursday, January 04, 2007 11:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [OpenID] T
Hey Sam,
I'm surprised the LJ implementation chooses the former since even the
1.1 spec in Brad's original form (http://openid.net/specs/specs-1.1.bml)
says:
> Note that the user can leave off "http://"; and the trailing
> "/". A consumer must canonicalize the URL, following redirects
> and noting
You're right, David -- the only real effect in the spec should be that an
HXRI is recognized as being an XRI (and not a URL) from the standpoint of
what the RP should do once it gets back the XRDS document, i.e., the RP MUST
use the CanonicalID i-number and not the original HXRI.
That would solve
Bob,
>From the report you show, the Yadis diagnostic is doing the correct
resolution call to the xri.net HXRI proxy resolver. So it's sites that have
the pre-Yadis RP libraries that won't yet work with HXRIs (or with any other
Yadis-enable URL for that matter). Those libraries are only looking
10 matches
Mail list logo
