Comments (7)
from paseto.
Let me attempt to answer this line-by-line, then document it:
-
How payloads represented as strings should be encoded into bytes (utf8?)
- Yes, UTF-8.
-
Is a JSON encoded payload part of the spec? Is it required that (received||sent) payloads are in this format, or optional?
- Originally it was going to be optional so people could use Protobuf, etc. However, I've since decided to just use JSON.
-
Specify the type (or even data) structure (if any) that the JSON payload should conform too
- Reference implementation appears to hint that this is
array<string, string>
, but I think it actually allowsarray<string, mixed>
due to a type hint diverging with the doc block. See also probable need for type validation on bulk setting of claims.
- OK.
- Reference implementation appears to hint that this is
-
Are arbitrary keys allowed to be set? (or is there a reserved character set for example?)
- By keys do you mean in the array<key, value> sense? If so, there are "registered claims" which are very similar to JOSE's, except we use ISO 8601 datetime strings rather than unix timestamps.
-
Are any keys reserved for certain purposes? (e.g. the ones used for rules like expiry)
-
Are these reservations case sensitive? (e.g. should an expiry key with incorrect case be ignored?)
-
Should users be allowed to set reserved keys like arbitrary other keys, or should distinct mechanisms be enforced?
-
If users can set these, do we fail if the user puts unexpected (e.g. unparseable) data in these reserved fields (i.e. should writes to reserved fields be validated)?
- Users should not (but not 'MUST NOT') write arbitrary/invalid data to reserved fields (
exp
,iat,
nbf
, etc.)
- Users should not (but not 'MUST NOT') write arbitrary/invalid data to reserved fields (
-
Are rules part of the spec? (if so what are they?)
- No, we only provide them in the reference implementation for convenience.
-
Are rules specified as reserved keys, or are they in a structurally different part of the JSON payload to user data?
-
Is rule validation required? (if no, what should be the default?)
- No, that entirely depends on what the application is doing with the tokens. Some people will only want tamper-proof cookies. Some people want the full shebang of JOSE features.
-
Do we fail open or closed if a rule is of an unexpected format?
-
Will payload processing receive spec updates (e.g. potential changes to rules, addition of rules), how should this be versioned?
-
If payload processing is versioned, where do we put this version?
Anything unanswered (bold) is something I'm not sure about yet.
from paseto.
Are arbitrary keys allowed to be set?
- By keys do you mean in the array<key, value> sense? If so, there are "registered claims" which are very similar to JOSE's, except we use ISO 8601 datetime strings rather than unix timestamps
Indeed, assuming the JSON structure is array<key, value>
, this question is referring only to the key portion.
This is to ask whether:
- Should conforming implementations allow users to pick their own keys, or is there some sort of whitelist (as fas as I know, answer is: user may pick keys)
- Are there restrictions on what a key can look like (e.g. character set, casing, whitespace, ...).
With regard to the values, e.g. date formats, this comes under:
do we fail if the user puts unexpected (e.g. unparseable) data in these reserved fields (i.e. should writes to reserved fields be validated)?
which you've already answered :)
It's more than okay for the answer to some of these to be: "undefined", or "application specific", ... (some of these questions are really just aimed at pulling spec details out of the reference implementation)
from paseto.
Originally it was going to be optional so people could use Protobuf, etc. However, I've since decided to just use JSON.
I'll assume that means I should make the JSON-specific route the favored option in my examples, and provide the raw-payload binary data only through a secondary route. Currently pypaseto only handles the raw portion, but I intend to build support for JSON and validation of registered claims soon.
I'm interested in getting msgpack functional as well, although due to the mostly-compatible nature, the processing of claims could actually be identical just with the middle encoding layer swapped out.
from paseto.
I'll assume that means I should make the JSON-specific route the favored option in my examples, and provide the raw-payload binary data only through a secondary route.
👍
from paseto.
This should be unambiguous enough now that #59 is merged. I'll reread this tonight and make sure before I close it.
from paseto.
This should be unambiguous enough now that #59 is merged. I'll reread this tonight and make sure before I close it.
Yeah, I think #59 pretty much answers everything. I've checked everything above that I think has been explicitly answered. For what remains I would assume the following answers by omission:
Are these reservations case sensitive? (e.g. should an expiry key with incorrect case be ignored?)
Yes, case-sensitive.
If users can set these, do we fail if the user puts unexpected (e.g. unparseable) data in these reserved fields (i.e. should writes to reserved fields be validated)?
Up to implementation to come up with a means of discouraging invalid writes.
Do we fail open or closed if a rule is of an unexpected format?
Closed. (i.e. rule fails)
Will payload processing receive spec updates (e.g. potential changes to rules, addition of rules), how should this be versioned?
Unknown. (no mention of versioning for payload processing, leaning towards: No, this is a static requirement).
If payload processing is versioned, where do we put this version?
Unknown / n/a
from paseto.
Related Issues (20)
- How to use public private key pair? HOT 1
- PHP 8 support HOT 2
- DOWN : paseto.io HOT 1
- New Registered Claim: Token Generation? HOT 2
- Support Multiple Keys in Builders/Parsers HOT 1
- Null salt? HOT 5
- Mention paserk-php in README HOT 2
- Parser::parse(): Expiration check skipped if no other rules are defined HOT 1
- Class \"ParagonIE\\Paseto\\Protocol\\Version4\ Not found HOT 5
- Non-string claim values? HOT 3
- Is there a standard way to generate paseto tokens with human-readable payload without verification? HOT 2
- Questions on Assymetric Keys HOT 5
- I can't get Version 3 working HOT 2
- Invalid MAC for given ciphertext HOT 2
- Attempting to Catch Invalid ed25519 Private Keys HOT 6
- Cannot read pem created with encodePem HOT 4
- [Version 3] Cannot create token from encoded private key
- Undefined array key "ParagonIE\Paseto\Keys\SymmetricKey" HOT 1
- v4: read claims of an expired token HOT 2
- [V1] Vulnerability flag due to phpseclib/phpseclib < 3 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from paseto.