RE: [dss] Representing requestor's identity

["Nick Pope" <pope@secstan.com>]

Trevor,

What exactly do you mean by ASN.1 syntax?  Do you mean take the basic ASN.1
structure and redefine it in XML?  If so I agree.  There needs to be work
done on how some of the more complicated types are represented.  In
particular the directoryName needs to be encoded in LDAP, IP address should
be in the dotted form.  Also, instead of each "name form" having a separate
tag for each type.  A more generic approach could be a "name form"
identifier followed by the Name value encoded as a string.

If you mean take the BER encoding of the ASN.1 structure and then base64 it,
then I strongly disagree.  Even just blindly taking the complicated inner
ASN.1 structures and converting them to XML, e.g. using XER, is not much
help  Any ASN.1 based parsing would be hidden within object modules handling
CMS / X.509 certificate structures.  Not generally useful when parsing the
XML data.

..... <snip>

>
> My new opinion is that for CMS we should choose a single ASN.1
> name syntax
> (probably GeneralName), and for XML-DSIG we should choose a
> single XML name
> syntax (either define our own, or borrow SAML <NameIdentifier>).  I think
> extensibility to different name forms is important, but to different name
> syntaxes would cause needless incompatibilities (e.g. if Alice encodes an
> email address in one syntax, and Bob can only understand it in a
> different
> one).
>

> Then for both XML-DSIG and CMS, we should allow the use of a SAML
> Assertion
> in place of the name syntax when information about the
> authentication is to
> be represented.
>
As well as SAML we still need to cover WSS UsernameToken and allow other
externally defined structures for representing authenticated identities.

> This leaves open what XML name syntax we use - make our own or borrow
> SAML's?  But otherwise, using name syntaxes instead of Assertions avoids
> the verbosity and need to parse SAML Assertions when they're not
> necessary.
>
Keep it simple!

Nick