Mark and Signed Mark Objects Mapping

Abstract element types (<mark:abstractMark> and <smd:abstractSignedMark>) are defined to support additional mark and signed mark definitions through XML schema substitution groups, enabling extensibility without schema changes to the base types.

The <mark:id> and <smd:id> values are composed of a local identifier plus an issuer identifier to uniquely identify marks and SMDs across repositories potentially maintained by more than one issuer, avoiding collisions in a multi-issuer environment.

registry

The specification defers detailed PKI policy, authorized validators, and other operational requirements to local policy of entities using it (e.g., the ICANN TMCH for gTLDs), making the format reusable outside the gTLD context.

pkix, registry

The Mark and Signed Mark objects are designed to be referenced by application protocols such as the Extensible Provisioning Protocol (EPP, RFC 5730), and are used in the EPP Launch Phase Mapping extension.

Because SMDs may be transmitted as part of a protocol already based on XML, exclusive XML canonicalization as defined in XMLC14N MUST be used when creating an SMD's digital signature.

security, crypto

For the <mark:holder> element, at least one of <mark:name> or <mark:org> MUST be specified; each is OPTIONAL only when the other is present.

Implementations MUST NOT depend on XML namespace prefixes (e.g., 'smd' or 'mark') and MUST instead employ a proper namespace-aware XML parser and serializer to interpret and output XML documents.

It is RECOMMENDED that SMDs do not include white space between XML elements, in order to mitigate risks of invalidating the digital signature when SMDs are transferred between applications.

security, crypto

The digital signature algorithm used in Signed Mark objects SHOULD be RSA-SHA256, and the RSA key SHOULD be at least 2048 bits. Deviation is only justified if RSA-SHA256 is deemed insufficient.

security, crypto

When <mark:region> is specified in a <mark:court> element, a default-deny approach MUST be assumed regarding the regions of a country, meaning protection applies only to the explicitly listed regions.

XML specifications and examples in this document MUST be interpreted in the character case presented in order to develop a conforming implementation, because XML is case sensitive.

The <mark:court> element represents a court-validated mark with fields for <mark:refNum> (court opinion reference), <mark:proDate>, <mark:cc> (court country), optional <mark:region> elements, and <mark:courtName>. When <mark:region> is specified, a default-deny approach regarding a country's regions MUST be assumed.

registry

The <mark:mark> element describes an applicant's prior right to a domain name and contains one or more <mark:trademark>, <mark:treatyOrStatute>, and <mark:court> child elements. It substitutes for the abstract <mark:abstractMark> element, enabling extension via XML schema substitution groups.

registry, security

The <mark:trademark> element represents a registered trademark and contains fields including <mark:id>, <mark:markName>, one or more <mark:holder> elements, <mark:jurisdiction> (two-character WIPO ST.3 code), <mark:goodsAndServices>, <mark:regNum>, <mark:regDate>, and optional <mark:label> (A-label DNS forms), <mark:class> (WIPO Nice Classification), and expiry date.

registry, dns

The <mark:treatyOrStatute> element represents a mark protected by statute or treaty, including one or more <mark:protection> elements that identify countries and regions of protection via ISO 3166-2 country codes, optional regions, and optional ruling territory codes.

registry

The <smd:encodedSignedMark> element contains an encoded form of a Signed Mark Document (SMD) with an 'encoding' attribute defaulting to 'base64'. It allows transmission of an SMD as a simple string value.

security

The <smd:issuerInfo> element identifies the issuer of a mark registration via a required 'issuerID' attribute, and child elements <smd:org>, <smd:email>, optional <smd:url>, and optional <smd:voice>.

registry

The <smd:signedMark> element is a digitally signed XML document using XML Signature. It includes a required 'id' attribute of type XSD ID, and child elements: <smd:id>, <smd:issuerInfo>, <smd:notBefore>, <smd:notAfter>, <mark:mark>, and a <Signature> element.

security, crypto

IANA registered four URIs under the IETF XML Registry (RFC 3688): the signedMark-1.0 namespace (urn:ietf:params:xml:ns:signedMark-1.0), the signedMark-1.0 schema (urn:ietf:params:xml:schema:signedMark-1.0), the mark-1.0 namespace (urn:ietf:params:xml:ns:mark-1.0), and the mark-1.0 schema (urn:ietf:params:xml:schema:mark-1.0).

registry

A party using Signed Mark objects must verify that the digital signature is valid based on local policy. A PKI (or equivalent) must be implemented for the signatures to have any useful semantics; for gTLDs, the policy is defined in the ICANN TMCH Rights Protection Mechanism Requirements.

security, crypto, pkix

The security of a Signed Mark object depends entirely on the security of the underlying XML Digital Signature (DSIG) algorithms; all security considerations from the XMLDSIG specification apply.

security, crypto

Country code elements (<mark:cc>) are exactly two characters as defined by ISO 3166-2; postal codes (<mark:pc>) are tokens of at most 16 characters.

Mark and SMD identifiers use the <mark:id> type, encoded as a concatenation of a local identifier, a hyphen ('-', ASCII 0x002D), and an issuer identifier. The XSD pattern is '\d+-\d+'.

Telephone number elements (<mark:voice>, <mark:fax>, <smd:voice>) MUST begin with a plus sign ('+', ASCII 0x002B), followed by an ITU E.164 country code, a dot ('.', ASCII 0x002E), and digits. Maximum length is 17 characters. An optional 'x' attribute carries extension information.

The <mark:label> element encodes a DNS A-label form (per RFC 5890) of a label corresponding to the mark name, with length 1–63 characters and pattern [a-zA-Z0-9]([a-zA-Z0-9\-]*[a-zA-Z0-9])?.

dns