PEN 66398: Mobile-ID Standardizes OID for Its Ecosystem
IANA granted Mobile-ID PEN 66398, corresponding to root OID 1.3.6.1.4.1.66398. This is the foundation for a stable identity mechanism across products, services, technical specifications and components throughout the entire ecosystem.
- 01PEN 66398Verified identity source
- 02Root OIDAnchor point for sub-branches
- 03GovernanceClassification, approval, lifecycle
- 04RegistryLookup and machine processing
- 05ApplicationProducts, customers, partners
Article Contents
Key Takeaways
- IANA granted Mobile-ID PEN 66398, corresponding to root OID 1.3.6.1.4.1.66398.
- A PEN and an OID are technical identity records; they are not a certification of quality, a service license or a confirmation of compliance.
- The root OID anchors a governance model built on clear classification, approval, registry and lifecycle rules.
- The classification structure and registry model in this article are a reference architecture, not a list of OIDs officially issued by Mobile-ID.
- The OID registry combines a human-readable lookup interface with structured data (JSON, YAML, CSV) for automated system checks.
From an IANA Record to Ecosystem Governance Capability
For a technology company with many products, services and digital-trust components, the challenge isn’t just naming. What matters more is maintaining a stable identifier — one that is machine-processable, has a clearly responsible unit, and remains traceable when a commercial name, version or deployment model changes.
The Problem
Commercial names, URLs and version numbers can change or be understood differently across teams.
The Approach
Use root OID 1.3.6.1.4.1.66398 as an anchor, paired with clear classification and disclosure principles.
Technical Value
Link certificate policies, API specifications, evidence, devices and documentation through a stable identifier.
Business Value
Reduce ambiguity in bids, partner onboarding and long-term compatibility governance.
As the Ecosystem Grows, a Name Alone Isn’t Enough
Product names are useful for marketing and sales, but aren’t always a good identity key for systems. A platform can have many modules, API specifications, policies and deployment forms, while customers still need to know exactly which component is being applied.
Four Common Sources of Ambiguity
- Rebranding or product restructuring: the commercial name changes, but integration documentation needs to stay continuous.
- Multiple technical variants: the same product can have several specifications, assurance levels and deployment options.
- Documentation debt: teams can easily reference different versions when there is no central registry.
- Unclear lifecycle: partners may keep using a specification that’s no longer recommended if its status isn’t disclosed.
What Do PEN 66398 and Mobile-ID’s Root OID Mean?
Private Enterprise Number – PEN is a private enterprise identifier managed by IANA. IANA
recorded PEN 66398 for Mobile-ID Technologies And Services Joint Stock Company. The common PEN prefix is
1.3.6.1.4.1; so the corresponding root OID is 1.3.6.1.4.1.66398.[1]
Object Identifier – OID is a hierarchical identifier used across many technical standards. An OID can identify an organization, a certificate policy, an extension field, an algorithm, a data type or a protocol specification. ITU-T X.660 describes the international identifier tree and the operating principles of OID registration authorities.[5]
Technical Meaning
Stable, hierarchical, and well-suited to policies, extension fields, MIBs and specifications.
Access Address
Indicates where to access documentation or an API, but can change with infrastructure.
Unique Code
Well-suited for records or transactions, but doesn’t inherently express a governance tree.
Market Language
Easy to remember and communicate, but can change with branding strategy.
From a Root OID to an Accountable Identity Mechanism
An OID only creates value when paired with classification rules, clear responsibility, a review process and lookup capability. The model below separates the number source, the enterprise’s governance layer, and the value activated for products, customers and partners.
Identity Source
IANA grants PEN 66398, creating root OID 1.3.6.1.4.1.66398.
Governance Layer
Classification, review, approval, lifecycle management and registry publication.
Applied Value
Products and partners get a clear reference for scope, version and status.
Clear Enough for Today, Open Enough for the Future
The classification structure should reflect responsibility domains that stay stable over the long term, rather than being tied tightly to a product name at a single point in time. This approach lets Mobile-ID add products or restructure its registry without breaking its identity history.
1.3.6.1.4.1.66398Governance and Products
Organization, policy, products and platforms.
Digital Trust and PKI
Trust services, policies and extension fields.
Protocols and Data
APIs, identity, authentication, evidence and data types.
Devices and Integration
Security components and partner integration specifications.
Testing
A separate space for research and testing.
One Unified Identity Layer Across the Entire Digital Transaction Chain
From identity, authentication and digital signing through to delivery, evidence and payment, an OID lets every specification be recognized stably, traced and managed throughout its lifecycle. An OID doesn’t replace each business step; it creates a shared reference point between them.
Identity
Identity profile and assurance level
Authentication
Authentication method and applicable policy
Digital Signing
Signing policy and signature format
Electronic Delivery
Delivery specification and receipt structure
Electronic Evidence
Evidence type and data structure
Payment
Transaction type and receipt structure
Five Solution Domains, One Unified Identity Principle
The value of an enterprise identity space isn’t limited to PKI. The same principle can support identifying specifications, policies, evidence types, devices and integration relationships across solution domains.
Identity and Access
Trusted AccessID, GoPaperless SSO, Trusted SIC, FIDO2.
Digital Signing and Trust
GoPaperless, Trusted Key, PKI, TSA and PQC.
Delivery and Evidence
Trusted Delivery, electronic evidence and data-message authentication.
Payments and Transactions
Trusted Pay, Trusted PalmPay and Trusted Billing.
Devices and Security
CheckID, KioWare, Secure Token, USIM and biometric devices.
An OID Creates Value When Multiple Organizations Must Share the Same Understanding of a Specification
The three scenarios below show that an OID isn’t just a coding exercise; it’s a tool for reducing ambiguity when a solution passes through multiple systems, documents and responsible parties.
Integrating Multiple Services Within One Transaction Journey
A bank may use identity, authentication, digital signing, delivery, evidence and payment at the same time. An OID helps precisely identify the certificate policy, signing specification, API specification, evidence type and lifecycle status of each component.
Result: less time spent reconciling documentation, clearer compatibility, and better control over technical changes.Exchanging Data Messages With Long-Term Traceability Requirements
An OID can serve as a stable reference for message type, signing policy, delivery specification, evidence structure, retention policy and audit rules.
Result: greater consistency between business processes, technical documentation and stored evidence.Distinguishing Products, Modules and Compatible Specifications
An OID helps clearly distinguish device type, security module, embedded software, protocol specification, and production versus test environments.
Result: lower risk of integrating the wrong version, and a durable reference for OEM documentation.Every Role Sees a Different Value From the Same Identity Mechanism
Registry Governance and Continuity
Keep identifiers stable through rebranding, module splits or changes to product packaging.
Reduce Architectural Debt
Create a clear identity space with a responsible unit, status and replacement relationships between specifications.
Policy Traceability
Pinpoint exactly which certificate policy, extension field or evidence type is being applied.
Clearer Documentation
Tie proposals and compliance matrices to the correct technical specification, reducing vague descriptions.
Self-Serve Compatibility Lookup
Check scope, version, documentation and status without relying entirely on manual back-and-forth.
Accurate Component Reconciliation
Distinguish commercial names, document versions and the actual technical object being supplied.
The OID Lifecycle: From Request to Preserving History
Every OID must be reviewed, approved, published and managed throughout its lifecycle. Once retired, an OID is still preserved for historical lookup and must never be reused for a different meaning.
OID lifecycle on mobile
Initiation and Control
-
01
Request SubmittedState the need, scope of use and responsible unit.
-
02
Under ReviewCheck for duplication, technical meaning, scope and related documentation.
-
03
ApprovedThe OID is accepted and recorded in the governance registry.
Operation
-
04
ActiveThe OID is in use in official documentation, systems or specifications.
End of Life
-
05
No Longer RecommendedNot used for new deployments, but still maintained for compatibility.
-
06
RetiredKept only for historical lookup; never deleted and never reused.
Durable Identity, Controlled Status
An OID is not a temporary data key. Retiring it doesn’t make it disappear; the registry must keep recording its status, related documentation and any replacement OID. Not every software version needs a new OID — a new one is only needed when the technical meaning or identification scope changes.
One Source for People, One Data Feed for Systems
A web interface helps customers and partners understand what an OID means. JSON, YAML or CSV data lets systems automatically check status, version and replacement relationships.
For People
Name, description, object group, responsible unit, status, documentation and replacement relationships.
For Systems
JSON, YAML, CSV or an API to automatically check OID and lifecycle status.
{
"oid": "1.3.6.1.4.1.66398.<branch>.<object>",
"official_name": "...",
"category": "...",
"responsible_unit": "...",
"lifecycle_status": "active",
"specification_url": "https://..."
}An OID Turns a Generic Description Into a Verifiable Reference
In proposals, bids or integration documentation, a product name is often not enough to precisely identify a technical component. An OID linked to specification documentation and lifecycle status creates a reference point that sellers, buyers and integrators can all check against.
Bids and Proposals
State the specification, policy or evidence type explicitly instead of describing it by commercial name.
Compliance Matrix
Link each requirement to a technical object and version-controlled source document.
Solution Architecture Documentation
Show the boundaries between products, protocols, policies and device components.
Integration Specification
Help partners identify the correct API specification, data schema, signature format or evidence package.
Security Questionnaire
Reference the exact certificate policy, algorithm and extension field involved.
Partner Onboarding Checklist
Confirm version, status and documentation before moving a configuration into production.
Measuring the Quality of Governance, Not Just Counting OIDs
The metrics below are a reference framework for businesses implementing OID governance; they are not Mobile-ID’s current operating figures.
Share of important products, services and specifications that already have a registry record.
Share of OIDs with an identified responsible unit and approver.
Share of OIDs with specification documentation, change history and replacement relationships.
Number of detected duplicates, ambiguous cases, or scope misuse.
Time from request intake to decision and registry update.
Share of partner questions resolvable directly from the registry and linked documentation.
A Three-Stage Framework for Rolling Out OID Governance
The framework below is a reference: start with principles and responsibility, then move to inventorying technical assets and standardizing data, and finally publish a lookup mechanism suited to each user group.
Establish Governance Principles
- Define scope and goals
- Assign responsibility
- Build the classification structure
- Define the review process
Inventory and Standardize
- Inventory products, services and specifications
- Classify production vs. test
- Detect duplicate or ambiguous identifiers
- Link to source documentation
Publish and Adopt
- Build the lookup interface and data
- Update product and integration documentation
- Train teams and partners
- Set up a periodic review cycle
Questions That Need Consistent Answers About PEN and OID
What does PEN 66398 mean?
It is the Private Enterprise Number assigned by IANA to Mobile-ID Technologies And Services
Joint Stock Company. Combined with the PEN prefix 1.3.6.1.4.1, the organization’s
root OID is 1.3.6.1.4.1.66398.
What is Mobile-ID’s root OID?
The root OID is 1.3.6.1.4.1.66398. Sub-branches can be organized and governed by
Mobile-ID according to product, service and technical needs.
Does IANA certify Mobile-ID’s products?
No. The PEN registry is a technical identifier registration mechanism. Holding a PEN does not certify the quality, security, compliance or licensing of any product or service.
Does an OID replace an API URL?
No. A URL indicates where to access an endpoint or document; an OID identifies technical meaning or specification. The two are complementary.
Does an OID replace a version number?
No. A version number describes changes to a document or product; an OID identifies the object or its technical meaning.
When is a new OID needed?
When a new object needs to be identified, or when the technical meaning changes enough that it is no longer compatible with the previous identifier.
Can a retired OID be reused?
It should not be. An issued OID must keep its original meaning to preserve traceability; the old record must continue to show its status and any replacement OID.
Can partners create their own branches under Mobile-ID’s OID?
Only with a clear delegation mechanism and governance rules from Mobile-ID. Uncontrolled branch creation can cause duplication.
Should the OID registry be made public?
Records that customers and partners need to verify specifications, status and reference documentation should be made public; sensitive objects can be managed with appropriate access scope.
What value does an OID bring to enterprise customers?
An OID helps customers precisely identify the component and specification being applied, reducing ambiguity in integration and increasing consistency between business and technical documentation.
Official Sources Used for Verification and Content Direction
- IANA — Private Enterprise Numbers, PEN 66398 record: confirms PEN 66398 is assigned to Mobile-ID Technologies And Services Joint Stock Company and that the PEN prefix is 1.3.6.1.4.1.
- RFC 9371 — Registration Procedures for Private Enterprise Numbers: describes the registration procedure and scope of use for a PEN.
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile: describes the X.509 certificate profile and the extension fields identified by OIDs.
- RFC 3647 — Certificate Policy and Certification Practices Framework: a content framework for certificate policy and certification practice statements.
- ITU-T X.660: operating principles for OID registration authorities and the top-level arcs of the international identifier tree.
An OID Is More Than Just a String of Numbers
When properly governed, an OID becomes a stable identity layer that connects architecture, products, documentation, evidence and partner relationships across the entire technology lifecycle. PEN 66398 gives Mobile-ID an anchor point for standardizing technical assets under one unified identity space.
Community Discussion