[urn] Re: Request for globalplatform URN

[Jeremy O'Donoghue <[e-mail]>]

Hi all,

> > On 7/13/26 9:45 AM, Jeremy O'Donoghue wrote:
> >> I would like to register a URN namespace for use in GlobalPlatform
> >> specifications. GlobalPlatform is a non-profit industry body
> >> publishing specifications for security components. The public website
> >> is at https://globalplatform.org <https://globalplatform.org>
> >>
> >> Below information follows the RFC8141 template:
> 
> Does this registration has any relationship to the effort discussed in Kate Gray's
> e-mail
> https://mailarchive.ietf.org/arch/msg/urn/RiNCn4BYeY6xoilYpiGdDBUd0QQ
> et seq.?

[Jeremy O'Donoghue wrote] 
This is entirely unrelated to Kate's request. 

Based on what I can infer from Kate's request, she is proposing a URN supporting an open but proprietary scheme for managing key derivations in a card issuance scheme which is not intended to be, or advertised as, compliant with GlobalPlatform specifications.

It might make sense to ask Kate to remove the reference to GlobalPlatform keys in the template as: 

1. It doesn't seem to be relevant to the technical intent of the registration; 
2. It is not correct - GlobalPlatform cards supporting the latest specifications (GlobalPlatform Card Specification, Amendment N, v1.0) support AAD of 16..512 bytes for key derivation.
3. It avoids any confusion about whether this scheme is in any way associated with GlobalPlatform, which it is not.

> 
> >> Namespace Identifier:  Requested of IANA (formal): globalplatform
> >> Version:  1 Date:  2026-08-30 Registrant:
> >>
> >>   *
> >>     GlobalPlatform Inc.
> >>     544 Hillside Rd., Redwood City, CA 94062-3345
> >>     United States of America
> >>   *
> >>     Contact: [e-mail]
> >>
> >> Purpose:
> >>
> >>   *
> >>     GlobalPlatform uses IETF specifications as a basis to provide
> >>     interoperability with other ecosystems. It typically defines
> >>     profiles of IETF specifications which provide specific support for
> >>     GlobalPlatform secure components. IETF specifications often prefer
> >>     URN namespaces for such profiles. Use of an allocated URN is
> >>     therefore desirable for interoperability.
> >>   *
> >>     The specific initial need is to define RFC9711 compliant profiles
> >>     for GlobalPlatform Trusted Execution Environment and Secure Element
> >>     components.
> >>
> >> Syntax:
> >> URNs compliant with this specification SHALL use only ASCII upper and
> >> lower case characters, the digits 0-9 and the '/', '-', ':' and '.'
> >> characters. Upper-case ASCII characters SHALL be transformed into
> >> their lower case equivalents before processing.
> >> Assignment:
> >>
> >>   *
> >>     Closed assignment in GlobalPlatform specifications.
> >>
> >> Security and Privacy:
> >>
> >>   *
> >>     URNs in this namespace SHALL NOT be used as security capabilities
> >>   *
> >>     URNs MAY be distributed to untrusted entities
> >>   *
> >>     URNs in this namespace SHOULD NOT be used to convey information
> that
> >>     can uniquely identify a specific instance of a GlobalPlatform Secure
> >>     Component
> >>   *
> >>     Incorrect or ambiguous resolution of URN-equivalence SHALL
> 
> This sentence seems to be incomplete.
> 
> >> Interoperability:
> >>
> >>   *
> >>     None known
> >>
> >> Resolution:
> >>
> >>   *
> >>     Not anticipated
> >>
> >> Documentation:
> >>
> >>   *
> >>     None currently available as we have no URN namespace identifier as
> >>     yet. A specification will be published listing all assigned values
> >>     in this namespace.
> >>
> >> Additional Information:
> >>
> >>   *
> >>     N/A
> >>
> >> Revision Information:
> >>
> >>   *
> >>     N/A
> >>
> >>
> >> As the requester, I am editor of the GlobalPlatform Entity
> >> Attestation Protocol Specification and was one of the editors of
> >> RFC9711. The GlobalPlatform Entity Attestation Protocol specification
> >> plans to include RFC9711-compliant EAT profiles which can be
> >> interoperably identified by verifiers through the eat_profile claim.
> >>
> >> Assuming this allocation is granted, the profile identifiers will be
> >> for the form: "urn:globalplatform:profile:<profile_name>:<profile_version>"
> >> where <profile_name> is replaced with the profile name and
> >> <profile_version> is replaces with the version number of the profile.
> 
> It would be useful if this verbal description was turned into ABNF.  But as
> written, it seems to be very restrictive.  Are there long-term plans that would
> cause other categories of URNs in this namespace to be issued?  That would
> require updating the registration.
> 
> Dale