OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] ServerStatus element?


+1. I’ll be sure to include this in the ED04 spec text.

 

=Drummond

 


From: markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Thursday, August 23, 2007 6:36 PM
To: Drummond Reed
Cc: XRI TC
Subject: Re: [xri] ServerStatus element?

 


Sounds good to me. What happens if the server returns no Status at all (according to the schema it's optional)?
My idea would be that the resolver should then in any case create one and also add an empty ServerStatus.

Sorry all for having missed the call, will join tomorrow......

Markus

On 8/23/07, Drummond Reed < drummond.reed@cordance.net> wrote:

On today's telecon, in the first topic (excerpted in the minutes below), we
concluded that when a resolver needs to override the Status code/content
provided by the server, we should specify that the resolve MUST report to a
consuming application the status info originally supplied by the server by
adding an originalcode attribute (and optionally an originalcontent
attribute) to the Status element.

As I went to add this to ED04, it occurred to me that it would be cleaner
for the client to report the original server status using a ServerStatus
element. This would eliminate potential confusion over whether the
originalcontent attribute was optional or not.

The rules would be:

1) The server provides the original Status element in an XRD.

2) If the resolver agrees with this status, the resolver simply passes it on
to the consuming application; nothing is changed.

3) If a resolver needs to override the server-supplied Status (for instance,
if SAML signature validation fails, or CanonicalID verification fails), the
client MUST the name of the original Status element to ServerStatus
(preserving its original code= attribute and contents), and MUST add a new
Status element (with its own code= attribute and contents).

This way any consuming application that receives an error back from the
client but wants to know the original status code/contents sent by the
server can always get if from the ServerStatus element. It's also very
precise how the consuming application can recreate the original XRD returned
from the server if it wants to do its own check on a failed SAML signature,
for example.

Anyone who disagrees with this solution (vs. the solution proposed in the
telecon minutes, below), please post. Otherwise I'll add the ServerStatus
element and appropriate normative text to ED04.

=Drummond


> 1) RESOLVER BEHAVIOUR FOR SAML TRUSTED RESOLUTION ERRORS
>
> In working on his action item for ED03 Section 6.2.2., Wil had several
> question about how SAML signatures were incorporated into XRDs. This
> turned
> into a very long investigation of the requirements for XML digital
> signatures as constrained by section 5.4 of SAML Core
> (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf).
>
> The result was that we clarified the following:
>
> * SAML constrains the use of XML Dsig to enveloped signatures, and says
> you
> SHOULD NOT perform any transforms (such as excluding elements from the XML
> document to be signed) other than: a) the "enveloped signature" transform,
> which allows you to exclude the signature itself, and b) a standard XML
> canonicalization transform specified in XML Dsig. (We made some minor
> wording changes in ED03 section 8.2.2.2 to clarify this.)
>
> * This means that when saml=true in a resolution request, and a signed XRD
> is returned, the Status element will be part of the signed information and
> thus cannot be changed without breaking the signature.
>
> * We then discussed what behaviour a resolver should implement if the SAML
> signature does not validate. If the resolver overrides the Status code to
> indicate a failed signature, and then returns the XRD to the consuming
> application, the consuming application does not have the original data
> necessary to know the original status or do its own check on the signature
> (which may be useful for debugging).
>
> * Our conclusion was to solve this problem by having the resolver add two
> new attributes to the Status element: originalcode and originalcontent.
> The
> rule would be that: a) *anytime* a resolver needs to override the
> server-provided Status code, the resolver MUST add the originalcode
> attribute with the original server-supplied status code, and b) *anytime*
> a
> resolver needs to override the server-provided content of the Status
> element, the resolver MUST add the originalcontent attribute with the
> original server-supplied content.
>
> # DRUMMOND to make this change in ED04.
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]