... why not still use this XML structure and the "RetrievalMethod"
element within the XRDS so that can then point to a remote "KeyInfo"
element in another XML document?
+1
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/sp
Hopefully, everyone had the opportunity to read document I sent that outlines
the business scenario(s) we are interested in using OpenID for. Figured I would
start taking each theme and sharing requirements with the hope that others will
react.
The requirements for relationship are as follows:
Hey Grant,
I'm not sure if keys will really apply to a specific service element per
say. There certainly may be cases where they may, but in others someone
may want to define a generic key for their identifier. I think this is
however accomplished by placing the key in a "Service" element and
def
On 1/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Nope, it is still part of the "KeyInfo" element defined at
> http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo.
Ok. I didn't realize that functionality was already defined. I think
that seems like a reasonable change. I can't s
>From the v1.1 spec:
"It is RECOMMENDED Identity Provider's protect their End Users from
requests for things like http://*.com/ or http://*.co.uk/.";
Is there a list of such domains? Of course, one can take the list of
TLDs and ccTLDs, but as the *.co.uk example shows, there may be other
domains w
Nope, it is still part of the "KeyInfo" element defined at
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo.
So my thought is the XRDS could look like:
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo
http://www.w3.org/2000/09/xmldsig#PGPData
That sounds fine. I have never heard of the RetrievalMethod element,
so I can't really speak to whether that is the way to go or not. Is it
part of XRDS?
On 1/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> True, though why not still use this XML structure and the
> "RetrievalMethod" element wi
+1. A lot of thought went into the KeyInfo element design.
And the spec can define a valid subset of KeyInfos, too, if needed.
-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 09:50 AM Pacific Standard Time
To: Grant Monroe
Cc:
True, though why not still use this XML structure and the
"RetrievalMethod" element within the XRDS so that can then point to a
remote "KeyInfo" element in another XML document?
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Grant Monroe
Sent: F
On 1/4/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> 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
On 1/5/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
> The Attribute Type model is such that anyone with a domain can define
> new attributes. No need for central control. We created a set of what
> we thought were common attributes, but that does not mean anyone has
> to use them.
Being able to defin
> This naming scheme doesn't separate out extensions by what they're
> extending. Presumably in future we're going to have other
> non-extension specs (that is, they don't actually use the OpenID
> Authentication request as a transport) which will themselves have
extensions.
>
> How about,
http://s
Recordon, David wrote:
>
> http://specs.openid.net/authentication/2.0/signon
> http://specs.openid.net/authentication/2.0/server
> http://specs.openid.net/authentication/2.0/identifier_select
These seem just fine to me.
(+1, I guess!)
> So very verbose and organized. There is no need for an xml
Hi Rowan
We will be releasing a tweaked version of the Attribute Exchange spec
tomorrow. Adds a simple way to support requested and receiving
multiple values for the same type.
The old properties list is here: (there is a link to archives at the
bottom of the specs page on OpenID.net)
Drummond,
Thanks for the detailed response. BTW: Below, you'll see what is happening
when I use the Yadis diagnostic on the HXRI. I believe that users will, in
fact, expect XRI's, i-names, and HXRI's to be interchangeable. I'm using
2idi.com, so I guess I have to wait for them to put in the fix?
Bringing this back up as now with more extensions I think we need at
least some sort of naming scheme.
I'd propose we use for roots:
http://specs.openid.net/authentication/VERSION...
http://specs.openid.net/extensions/ABBREV/VERSION...
Then corresponding:
http://xmlns.openid.net/extensions/ABBREV
16 matches
Mail list logo
