Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incorporated subject identifiers from RFC9493 #57

Closed
wants to merge 1 commit into from
Closed

Conversation

tulshi
Copy link
Collaborator

@tulshi tulshi commented Dec 11, 2023

No description provided.

@tulshi tulshi linked an issue Dec 11, 2023 that may be closed by this pull request
@tr33
Copy link

tr33 commented Dec 12, 2023

question to definition of

"format": "ip_address",

the examples only contain IPv4 adresses. But IPv4 is overaged and new systems must be IPv6 compatible.
however, both address formats will remain in the wild for sure a long time.

Question: should the ip address be typed in order to distinguish between multiple versions an formats?
like to distinguish between address netmask (a.b.c.d/24) and IPv6?

also, IPv6 address can be formatted ambiguously (see Issue #46 )

@ogazitt
Copy link
Collaborator

ogazitt commented Dec 20, 2023

I get the value of relying on another established spec for subject identification, but I think there are 2-3 important use-cases missing:

  1. "format": "jwt": a base64 encoded JWT
    2."format": "sub": a subject (identity) which is the sub claim from a structured token like a JWT
  2. "format": "string": an opaque string (the PEP passes a string that is meaningful in the context of the policy being evaluated - e.g. it's a key that can be looked up by the policy and resolved into a subject)

In addition, would it make sense to allow something like "format": "anonymous" to be able to enforce policy that isn't subject-specific? For example, time of day or IP address range enforcement?

@@ -46,6 +46,7 @@ normative:
RFC6750: #OAuth 2.0 Bearer Tokens
RFC8259: #JSON
RFC9110: # HTTP Semantics
RFC9493: # Subject Identifiers for SETs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
RFC9493: # Subject Identifiers for SETs
RFC9493: # Subject Identifiers for Security Event Tokens


The following non-normative example describes a Subject:
The following is a non-normative example of a Subject Identifier Format of type Device Identifier:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The following is a non-normative example of a Subject Identifier Format of type Device Identifier:
The following is a non-normative example of a Subject Identifier Format of type Device Identifier:

@@ -383,7 +418,8 @@ X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
"subject": {
"id": "[email protected]",
"format": "email",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest using account, iss_sub or opaque in examples rather than email.

email is a problematic subject identifier because canonicalization algorithms for email addressees aren't that well defined. In some edge cases, it's barely possible to canonicalize email addresses, as a bright example, both [email protected] and [email protected] "represent" the same email address.

## IP Address {#ipaddress-registry-entry}

* Format Name: ip_address
* Format Description: A value that describes a subject through its IP Address
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Format Description: A value that describes a subject through its IP Address
* Format Description: A value that describes a subject through its IP address

@davidjbrossard
Copy link
Collaborator

I am closing this PR as we've since done major rework to the API that voids the work done in this PR.

@davidjbrossard davidjbrossard deleted the atul-issueres branch June 27, 2024 17:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

specify type for subjects
5 participants