[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Re: [saml-dev] status code value
Since we say "MUST be prefixed", I interpret this to mean that it's not acceptable to use a non-prefixed (but implicitly qualified) value. So I think Scott's first example wouldn't be correct. Comments from anyone on this? Do we need to broaden the language in a future version? Eve Scott Cantor wrote: >>"All status code values defined in this document are QNames >>associated with the SAML protocol namespace, and MUST be prefixed >>appropriately when they appear in SAML messages." >> >>To my understanding, this means a valid status code value >>would be: "urn:oasis:names:tc:SAML:1.0:protocol:Success" >> >>For example, >><abc:StatusCode xmlns:abc="urn:oasis:names:tc:SAML:1.0:protocol" >>Value="urn:oasis:names:tc:SAML:1.0:protocol:Success"/> > > > No, that's not a QName. A QName is a namespace prefix and a local name > (the prefix being optional), not a complete namespace and a local name. > > So you have to have: > > <StatusCode xmlns="urn:oasis:names:tc:SAML:1.0:protocol" > Value="Success"/> > > or > > <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" > Value="samlp:Success"/> > > There are inconsistencies in various XML APIs and specs in terms of > properly handling QNames in attribute values and element content, > because the usage wasn't initially expected or defined. But it's > increasingly common. > > Personally, I had to define a QName type and implement some of the > behavior I needed, but some parsers may provide some of that. > > -- Scott -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 883 5917 XML Web Services / Industry Initiatives eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC