Anonymous user

Talk:Yadis Resource Descriptor Draft 0.8

From Yadis

Jump to: navigation, search

This page is now only of historical interest.

[Excellent work here, folks. Please note the dates on my comments. -- Joaquin 22Dec5]

>> I've added some items to this page, taken from messages on the Yadis list and responded here. -- Joaquin

>> In Version 0.8, I've acted on all the comments on this page, except any after which I have added a note that I have put that item off for tonight. -- Joaquin 29Dec5

Contents
[edit]

6.3.1 More than one URI

6.3.1 says a Yadis Service element MUST NOT contain more than one URI element. Why this restriction? In XRI resolution architecture, the reason a Service may contain more than one URI element is redundancy, i.e., the same reasons you have DNS round-robin. So we specify that if you have more than one URI element, and the consuming application needs only one, you select the highest priority URI element. Is there a reason you don't want to allow this? =Drummond

Since we don't want to require following priority, though we certainly want it to remain there as an option, does it make sense that, if there is more than one URI, they all have the same meaning (except for priority) and a Relying Party can try any one or all of them (or may handle them as provided in XRI Resolution)? This seems consistent with the 'SHOULD' in 2.4.3 of XRI Resolution. -- Joaquin

Yes, this makes sense to me. That's the underlying rationale in XRI Resolution – that if there is more than one URI, they are all equivalent for the purposes of this Service. =Drummond

>> I've included this in v.0.8 --=joaquin

[edit]

6.3.2 Priority Attribute

In 6.3.2, Priority Attribute, you can (if you want) reference the section of the XRI Resolution spec that specifies priority attribute processing. (And if it's used with URI elements, this would kill two birds with one stone.)

>> I've included this in v.0.8. --http://myLID.net/joaquin

[edit]

6.3.6 Other XRDs and other elements in the XRDS

I suspect that the wording you want in the second line is not "first" or "all" but "last", i.e., if an XRDS document contains more than one XRD (as a result of XRI resolution across multiple delegation points, for example), then the XRD that describes the target resource is the last one (following XML document order). =Drummond

>> I've corrected this in v.0.8 and added emphasis on 'last.' --Joaquin


[edit]

Question about structure

Does the Service element belong to the XRID core namespace? What about URI? If not, shouldn't they be referenced by namespace, and what is the URI for that namespace? --Http://mylid.net/cgranade 15:48, 8 November 2005 (PST)

Both Service and URI are part of the XRID namespace. I'm honestly not up on my XML standards though so this most likely would be worth mentioning on the mailing list to get clairity. User: Anon

> I believe the namespace identifiers are required. Certainly if more than one namespace is used. (Notice that services can add elements to that they define for themselves.) The current text uses explicit namespace identifiers, except for XRD, which is the default namespace, by default. =Joaquin 29Nov5 and 25Dec5

In the spec on the OASIS website the outer two nodes are called XRDS and XRD, here XRIDS and XRID. I'm confused, or is this another type of document? --Http://mylid.net/lukasros 16:57, 28 November 2005 (PST)

The names have been changed, dropping the eyes. I have changed the page accordingly. http://mylid.net/joaquin 29 Nov 5

>> I believe v.0.8 is correct. -- Joaquin

[edit]

XML Namespaces

According to discussion on the mailing list, the XML namespace for XRID is xri://$res*schema/XRIDescriptor*($v*2.0). The made-up example TypeKey namespace also needs a declaration. We should change the example to something like this:


   
      expiry in XML date time
      persistent ID for XRID provider
      
          http://lid.netmesh.org/sso
          http://myid.example.com/lid
      
      
          http://openid.net/signon
          http://myid.example.com/openid
      
      
          http://www.typekey.com/signon
          exampleusername

I just made up a URL for the TypeKey thing. The speci should probably note that the TypeKey case here is just an example and that no actual spec for this exists at this time. If Six Apart wants to make one they can decide on the XML namespace and the service identifier themselves and document it somewhere.

In practice though, there's not much call for supporting TypeKey under Yadis since TypeKey has an OpenID server anyway.

<Josh Hoyt> I think there is a strong motivation for supplying TypeKey information, because it allows relying parties that already support TypeKey to use Yadis with much less overhead. There would be no requirement to implement OpenID or LID in order to start using Yadis.

. . . . .

To keep it simple for now, I will remove the TK Service. Joaquin 29 Nov 5

<Josh Hoyt> Another sample XRD document, as I understand the specification::




  

    
      http://openid.net/signon/1.0
      http://www.myopenid.com/server
      http://josh.myopenid.com/
    

    
      http://openid.net/signon/1.0
      http://www.schtuff.com/openid
      http://users.schtuff.com/josh
    

    
      http://openid.net/signon/1.0
      http://www.livejournal.com/openid/server.bml
      http://www.livejournal.com/users/nedthealpaca/
    

    
      http://www.sixapart.com/typekey/sso/1.0
      joshhoyt
    

    
      http://lid.netmesh.org/sso/2.0
      http://mylid.net/josh
    

    
      http://lid.netmesh.org/sso/1.0
      http://mylid.net/josh

Like your example, my example has fictional XML namespaces and service URIs. Key differences:

  • XRID(S) -> XRD(S) (and corresponding namespace changes)
  • No version attributes (not in the XRD schema)
  • Services are marked with a priority (as per XRD schema)
  • Expires element not used
  • OpenID delegate tag

>> I believe the namespaces are correct in v.0.8. I've removed TypeKey from the example. I've used the example above in v.0.8 with small changes. --Joaquin

[edit]

URI for GPG/PGP Keys

How would you list a GPG authentication? Would it be something like 0x9AF4D09E, or something like http://people.openng.org/cgranade/cgranade.asc" id="0x9AF4D09E" />? If there's an existing XML schema for key exchange, it would be good to reuse it rather than reinvent the (square) wheel, but there should be some support in Yadis for discovering GPG-based identities. --Http://mylid.net/cgranade 15:49, 10 November 2005 (PST)

That's a capability-specific issue which Yadis itself shouldn't tackle. The OpenID and LID capabilities shouldn't really be described in Yadis, but since Yadis was originally designed as an extension of OpenID and LID I think that's an acceptable exception. --Martin Atkins

I disagree. Yadis isn't too useful if something like LID needs to have its own capabilitiy discovery mechanism (called LID profiles so far) on top of Yadis; that's one level of indirection too many for my taste. I'd like to take the list of LID profiles and declare them to be Yadis capabilities on a 1:1 basis, and in the longer term, get rid of LID's own mechanism for profile discovery.

For example, the MinimumLID profile provides for GPG export. Why shouldn't somebody implementing OpenID, for example, who also would like to do GPG key distribution, advertise this by also supporting MinimumLID (and only that LID profile)?


>> I've made no change in v.0.8. --Joaquin

[edit]

XML parsing

It seems this capabilities format implies that every party must

  • Have an XML parser that is namespace aware, and
  • Be able to parse XRIs, since the namespace is XRI

The first constraint seems reasonable: Yadis can define de-facto usage of prefixes for all namespaces so that namespace-ignorant parsing could work.

The second XRI-parsing constraint seems more of a heavy undertaking, since XRIs can get pretty complicated. Is there a way to make this more light-weight? (Perhaps I misunderstand to what extend Yadis wants to depend on XRIs.)

<Martin Atkins> XML namespace URIs don't need to parsed. It is sufficient just to check if the declared string (the value of the xmlns attribute) is character-for-character identical to the reference URI. This is true whatever URI type is in use.
<Hans Granqvist> I agree, but you can't depend on the default namespace being used. For example:

is equal to

so you'd still have to parse the XML attributes properly, either by the XML parser or by semi-intelligent slicing/concatenating of the elem/attr strings yourself, which is error prone.

About my original second question: Is the XRI resolution URIs in /XRID/Service/@Type always from a predefined set of values? As an example, see http://gravesfam.com/mike/yadis.xml

<User:Josh Hoyt> It would be masocistic to try to parse a rich XML format without an XML parser, not to mention error-prone. XML parsers are available most everywhere.

XRDS/XRD/Service/Type element values are not the same as the namespace identifiers. For service discovery, there will not be a predefined set, since someone defining a new serice needs to be able to define a new set.

The namespace XRIs for XRDS and XRD /are/ predefined, and the exact string has to match for the document to be correct.

<Hans Granqvist>Okay, I think we're misunderstanding each other. Let me rephrase as direct questions:
  • Will Yadis make it a requirement to have an XML namespace-aware parser?
< Joaquin> I still have not done my homework on this, but i believe that this is not up to Yadis and that the answer has to be yes. Will someone give a definitive answer here? 30 Nov 5
  • Will Yadis ever want to resolve (parse) any of the XRIs given in xrd:XRD/xrd:Service/xrd:Type?
< Joaquin> Hmmm. The current spec depends on recognizing the types you are interested in. In the OpenID and LID cases, they will be URLs. They will be treated for the purpose of the capability document only as type names, and will not need to be parsed or resolved. Like in so many other cases, we can hope that there is a story told, or even more, if they are used to GET at the resource they locate. Do folks think I am right about this? 30 Nov 5
  • Will Yadis accept or define the inclusion of other elements the XRDs (other than xrd:XRD/xrd:Service)?
< Joaquin> The current spec says no other elements are used by Yadis, except those mentioned. Define: No. Accept: Well, not accept, but the current spec says it will have to skip over, since identity services are free to add their own elements, and people using XRI based identity services will certainly have other fields. 30 Nov 5
< Joaquin> Double Hmmm. My answer is that an implementor can ignore anything in the capability document except for the particular types they want to handle. For those, they have to implement something that can handle them. For example, if they want to handle the type that corresponds to LID, they have to be able to a) recognize the type name b) pick out the URL, if any c) execute the corresponding LID protocol. {Repeat previous sentence, replacing 'LID' with something and adding other steps if something is going to use other elements.} But, again, do folks think I am right about this? 30 Nov 5
In any case, I believe that an implementor does not even have to look at XRI's at all, unless they are inside a Service element of a type they are prepared to handle. Then, if they find an XRI, then need to be able to handle it. LID and OpenID will find XRIs, of course, but that is only because 'XRI' is defined so that the OpenID and LID URLs are XRIs. So implementors wanting to handle OpenID and LID don't need to handle XRIs, except when they are URLs. If there is some other kind of XRI in a service element of type LID or OpenID, there is a semantic error in the capability document. Just as if is some string in a service element of type XRI, which is not a well formed XRI, there is a syntax or semantic error in the capability document.
<Kevin Turner> (channeling Josh):
  • XML namespace-aware parser? Yes. (Although I have a hunch you could make an implementation that would pass most non-pathological cases while ignoring the namespaces.)
  • Resolve XRI/URIs in "Type"? No. These are identifiers for the service type only, and do not need to be resolved.
  • Accept other XRD elements? Debatable. It's my personal opinion that if we are adopting XRD, we should not put additional restrictions on what is and isn't a valid Yadis XRD. Less muddy that way.
  • ...support all XRIs in section 2.2 (XRI Resolution Metadata for XRDs)? I'm not entirely sure what that would mean. I don't expect any party to have to resolve an XRI in the course of using Yadis. Nor do I expect any user's service document to include an XRI resolver service. If they do, I don't see how it falls in the scope of Yadis in any way. Iff you wish to use an XRI as an Identity URL, somebody somewhere probably has to care about section 2.2, but that's entirely outside the domain of Yadis.


>> I've made no change in v.0.8. --Joaquin

[edit]

Application type

Is it still application/xrid+xml? Will that change some day to application/xrd+xml? Joaquin 29 Nov 5

<Josh Hoyt> From the current XRI Resolution draft specification::
1263   For authority resolution, the “Content-type” header in the 2XX responses
       MUST contain the value
1264   “application/xrd+xml” or “application/xrd-saml+xml” specifying that the
       content is a
1265   generic XRD (section [3]) or a trusted XRD (section [4]) respectively.

The element names have been changed, dropping the eyes. I have changed the page accordingly. And later dropped the eye from the MIME type Joaquin 1Dec 5

>> I believe v.0.8 is correct. --Joaquin

[edit]

XML Signatures

"A Relying Party MAY ignore all other elements in an XRDS."

Is it permissible to have an XML signature enveloping the entire XRD document and have the signature be ignored by Yadis Relying Parties that do not wish to verify the signature?

--MarkWahl 14:38, 23 December 2005 (PST)

> Yes. That is the meaning of the present text. The effort has been to keep Yadis 1.0 as simple as possible. Joaquin 25Dec5

I am not familiar with XML signatures, but if it is really a wrapper:

 
 ...

then it will not work for spec-compliant consumers, because they expect the XRDS to be at the top level. The wording of the Yadis specification does not make it clear that the XML must match the structure defined in the XRI resolution specification.

I recommend: "The Yadis services document must contain only elements that match the structure defined in the XRI resolution specification."

--Josh Hoyt 08:58, 29 December 2005 (PST)

We should not mention XML signatures in Yadis 1.0 -- it would delay the release by months ;-). XML Signatures allow different places for where to put the signature, it would not necessarily corrupt the DTD/Schema. If we really need to define where they should and should not go, let's do that in Yadis 1.1 or 2.0.

--Johannes Ernst 14:47, 30 December 2005 PST


>> I've made no change in v.0.8. --Joaquin

[edit]

6.2.3 - no need to talk about Version

Section 6.2.3 talks about versions, but protocol versions are going to be entirely service-specific and aren't in the scope of the Yadis protocol. I don't think the Yadis specification should make recommendations about that at all.

--keturn 15:56, 27 December 2005 (PST)

+1

--Josh Hoyt 08:59, 29 December 2005 (PST)

We should add something like this:

  • implementations are strongly encouraged (but not required) to put a descriptive page at the URL that identifies the service type
  • implementations are strongly encourated (but not required) to include a version identifier into their URL in order to facilitate the evolution of their service in the future.

--Johannes Ernst 14:49, 30 December 2005 PST


>> I've made these two recommendations in v.0.8. --Joaquin

[edit]

6.2.4 XRDS

"The beginning of a Yadis Resource Descriptor is always the same" -- this is not true. It's quite possible to make a well-formed XML document using, for instance, a different encoding, or different prefixes for the XML namespaces. The way it's written now suggests that to do that would be out of spec.

--keturn 16:02, 27 December 2005 (PST)

>> I believe I've got this right now in v.0.8. Please check. --Joaquin

[edit]

6.3

There are some typos in the example. The closing bracket on the XRDS element needs to be after all the namespace declarations. The values of the namespace attributes must be quoted.

It would also be good to remove the typekey service, as Joaquin comment of 29 Nov notes.

--keturn 16:06, 27 December 2005 (PST)

+1 on removing TypeKey since there is no namespace or vocabulary currently defined.

--Josh Hoyt 09:01, 29 December 2005 (PST)

>> I've made the two corrections in v.0.8. Please continue to check. I have not run this through a checker or parser. --Joaquin

>> TypeKey is removed from the example. --Joaquin


[edit]

6.3.1

As I brought up in Talk:Draft 0.7 and Drummond points out, multiple URI elements are allowed in XRDS.

>> I've changed v.0.8 accordingly. --Joaquin



"If no URI element is provided, the service(s) identified by the Type element(s) MUST be provided by the resource identified by the Yadis ID."

This should be left up to the service. A TypeKey client, as an example, might reasonably connect to the central TypeKey server, not the Yadis ID.

--keturn 16:17, 27 December 2005 (PST)

>> There being no objection posted, I've removed this requirement from v.0.8. --Joaquin

[edit]

6.3.5

Can the example in 6.3.5 be merged with the example in 6.3? These two large example blocks seem redundant.

--keturn 16:36, 27 December 2005 (PST)

>> The examples illustrate different points. I have left them both in v.0.8. --Joaquin

Retrieved from "https://yadis.org/wiki/Talk:Yadis_Resource_Descriptor_Draft_0.8"
Personal tools