openid / openid/connect

E.164 phone number example is not accurately representing E.164 format

Open
#2,121 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

component: Core migrated-from-bitbucket priority: major type: bug
Dominant language
No language data
Stars
3
Forks
3
Avg merge
20h 14m
Merged PRs (30d)
1

Description

Originally submitted by Kyoho Satsumi (Kyoho Satsumi) on 2024-08-14

In section 5.1, phone_number member description:

End-User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 [RFC3966] extension syntax, for example, +1 (604) 555-1234;ext=5678.

While OIDC spec recommends E.164, the example shown here (including spaces, parentheses, and hyphens) is different from widely recognized E.164 format (no space/parenthesis/hyphen) , which I think it is confusing.

Here are couple of sources I found that explain E.164 formatting:

Is it possible to fix these examples in the errata?

Section 5.6.2.1. Example of Aggregated Claims and 5.6.2.2. Example of Distributed Claims also have phone number examples, which might want to be fixed together if this issue is approved.


Bitbucket status: open

Bitbucket origin: issue 2165

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with section 5.1, especially the phone_number member description and its E.164 and RFC 3966 references. Then review the phone number examples in sections 5.6.2.1 and 5.6.2.2, using the linked references to verify the formatting. Done means the affected examples consistently represent the intended formats and the errata addresses all relevant sections.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.