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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] A "final" proposal on status codes



Before this goes further, that is exactly what core25 says. 

I have sent it off to Jeff H. who is doing some unrelated tweakage.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Thursday, January 10, 2002 8:04 PM
> To: 'Hallam-Baker, Phillip'
> Cc: 'SAML'
> Subject: RE: [security-services] A "final" proposal on status codes
> 
> 
> > > The use of attributes/elements is a trickier problem, I think we 
> > > really should use attributes for exactly the same reason SOAP is
> using 
> > > elements, consistency with the overall coding style.
>  
> I don't mind attributes at all, but the SAML schema-24 as currently
> written only permits a single subcode, because the subcode is a single
> attribute of the top level Status element. If that's an 
> artifact of the
> recursion being deleted, that's fine, just mentioning it.
> 
> The way to keep the recursion and still use attributes is to have
> something like this:
> 
> <simpleType name="StatusCodeEnumType">
>     <restriction base="QName">
>         <enumeration value="samlp:Success"/>
>         <enumeration value="samlp:VersionMismatch"/>
>         <enumeration value="samlp:Responder"/>
>         <enumeration value="samlp:Requester"/>
>     </restriction>
> </simpleType>
> <complexType name="StatusCodeType">
>     <sequence>
>         <element name="Subcode" type="samlp:SubStatusCodeType"
> minOccurs="0"/>
>     </sequence>
>     <attribute name="Value" type="sampl:StatusCodeEnumType"
> use="required"/>
> </complexType>
> <complexType name="SubStatusCodeType">
>     <sequence>
>         <element name="Code" type="samlp:SubStatusCodeType"
> minOccurs="0"/>
>     </sequence>
>     <attribute name="Value" type="QName" use="required"/>
> </complexType>
> <complexType name="StatusType">
>     <sequence>
>         <element name="Code" type="samlp:StatusCodeType"/>
>         <element name="Message" type="string" minOccurs="0"
> maxOccurs="unbounded"/>
>         <element name="Detail" type="anyType" minOccurs="0"/>
>     </sequence>
> </complexType>
> 
> > > One issue that did occur to me is whether we should specify 
> > > which sub codes are permissible for which top level codes.
> 
> For the ones defined in the SAML spec, definitely. Obviously 
> this is an
> open-ended thing.
> 
> A given error condition code is defined by a sequence of 
> QNames, rooted
> in the SAML top-level codes, but by definition this isn't an 
> exhaustive
> list, and any status SAML defines can be "suffixed" with additional
> detail.
> 
> This is no different than the SOAP 1.1 dotted notation, just XML-ized.
> 
> -- Scott
> 

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC