CBOR encoded or, why not, ASN.1/DER
encoded.
To summarize :
Is the Status Lists a useful concept ? My answer is : no.
Should it be applied to X.509 certificates as well? My answer is : no.
Is there room for improvement? My answer is : yes, indeed. It is
possible to get rid of Status Lists and
e individual himself, e.g., because his
wallet has been lost or worse stolen. There is no "discrimination".
Denis
There is a huge hole here. Revocation of (for example) driving
privileges should not impact the use of the cred for other purposes.
The revocation idea can lead to c
allows to reduce the risks and hence to
improve
the security level.
eIDAS 2.0 does not currently allow the suspension state. Once, that
approach will be known, maybe the eIDAS.2.0 draft will be modified.
It is only a draft at this moment.
Denis
Orie - this is great work. I definitely think th
Hi Nikos,
You can take a look at:
https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html
Denis
Hi,
I am doing some research about work related to SD-JWT. I found this
old paper, which presents a solution similar to the SD-JWT disclosures
Ron Steinfeld et al
* because there was an unintentional leak of digital presentations or
some of their content, due to a security incident.
Denis
I'm not sure what the issue is but it appears commenting on the pull
request is possible because your comment shows up (twice even).
That said, I believe the sentiment of your s
erifier a digital presentation will be
or has been presented by a user.
Note:In this case, there is no need to have a collusion between an
Issuer and a Verifier.
Denis
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
res the use of a specific protocol
(preferably using ASN.1/DER) that can demonstrate:
* that the digital credential request comes from a wallet that has
"specific characteristics", AND
* that the public key or the Blinded Linked Secret indeed originates
from that wallet.
Denis
icate that
this digital credential, when stored in a wallet, is still under the
control of its digital credential issuer.
An I-D would be necessary (and sufficient) to define such policy identifier.
Denis
Ciao Denis,
OAuth Status Attestation was born because of some different approches
w
credential issuers”.
Theses approaches are alternatives to
draft-demarco-status-attestations-01 and to the"Token Status List"
approach that would be simpler to implement.
Also note that, at the moment, draft-demarco-status-attestations-01 does
not contain a "Privacy considerations&qu
pended, or by a WG issued from the SPICE BoF, if a WG
gets formed from it.
For the time being, in a future revision of this I-D, the privacy and
security considerations that apply to the OAuth 2 Framework
and to the “Issuer-Holder-Verifier model” should be clearly separated.
Denis
P.S. In sectio
Hi Giuseppe,
Ciao Denis,
Thank you! By points.
First, I still have a vocabulary problem. The text states:
A *digital credential* may be presented to a verifier long after it
has been issued.
It should rather say: A *digital proof *(derived from a digital
credential) may be presented
section is missing: "*Privacy considerations*".
One of many privacy principles is: "unlinkability between verifiers".
If or when the status attestation allows to support this privacy
principle, it should be indicated how it can be supported.
If or when it does not, this should be
Typo: Change:"proof _*or*_ origin of wallet instance"
into : "proof _*of*_ __origin of wallet instance".
The figure has been corrected below.
Denis
Hi Giuseppe,
The current figure in the Introduction from
draft-demarco-status
lder|| Verifier|
||--->||
+++---+
Denis
Hi Hannes,
Thank you for your quick reaction and also to Orie for sharing.
I've submitted the draft, here:
https://datatracker.ietf.org/doc/draft-demarco-status-attestations/
<https://datatracker.ietf.org/doc/draft-demarco-status-attestations
will be able to include into the specification these
templates, schemas or modules, but also derive files from them that
could be downloaded
from a web sitemanaged by the IETF so that they can be easily used by
implementers (i.e. without manually removing page headers and footers).
Denis
__
ist
since it addresses:
*oInteroperability considerations*
Its header will be: "About interoperability between independent
implementations".
Denis
ya know - there was a time when a standard could have a conformance
test and then the implementations worked together.
Now standards are
Hi George,
Is is unclear whether you are considering the OAuth 2.X Framework
or the three roles model (i.e., with the Holder, the Issuer and the
Verifier).
Denis
Hi,
Are there any best practices for clients that want to use Dynamic
Client Registration and plan to register a public key
Hi Neil,
On 7 Nov 2023, at 13:13, Denis wrote:
Hi Neil,
You wrote:
"Note that unlinkability is explicitly already not a goal for SD-JWT according
to section 12.4".
This is untrue:
12.4. Unlinkability
Colluding Issuer/Verifier or Verifier/Verifier pairs
tic to say the least
Why an "attacker" ? This is not problem as soon as a SD-JWT is only used
once.
Denis
On 6 Nov 2023, at 16:43, Watson Ladd wrote:
On Mon, Nov 6, 2023 at 5:46 AM Neil Madden wrote:
How about the following:
—
An Issuer MUST NOT allow any sec
equesting changes to the wording of the
proposed charter.
Please note that at this time, I don't agree with the current wording of
the SPICE BoF charter.
Denis
Hi Hannes,
Am 1. Nov. 2023, 12:21 +0100 schrieb Hannes Tschofenig
:
Hi all,
I am a bit puzzled by the response Pam and I
Hi Daniel,
Hi Denis,
a discussion on claims-based/biometric binding, probably what you're
hinting at,
I am not hinting at a discussion "on claims-based/biometric binding".
is out of the scope of this document, since we define neither
mechanisms nor rules for that.
This shou
uot;if he is not seen, he will not be
caught".
"Collaborative attacks against a Verifier" should be added to the
Security Considerations section.
There exist ways to counter collaborative attacks against a Verifier.
These ways should be mentioned in the core of the document.
Denis
Hi a
uld be a better renaming
for a version -01, since the token does need to be a JWT, nor a CWT.
Denis
I also noticed you didn't mark it as replacing the individual draft in
datatracker. You can email supp...@ietf.org and request that they mark it
as replacing
https://datatracker.ietf.o
Hi Carsten,
Thank you for your reply. Comments are in line.
On 15. Oct 2023, at 18:10, Denis wrote:
Hi Brian and Orie,
In the "old days", such problem did not existed. The prime example is using
ASN.1 / DER where the decoder can first know the full size of the message
using t
easons why the IETF has not considered such a
possibility,
but I don't know these reasons.
Denis
On Fri, Oct 13, 2023 at 3:53 PM Orie Steele
wrote:
Inline (and sorry for repeating points / rambling) :
No need to apologize.
It is, however, difficult (for me anyway) to engag
Hi David,
I am not referring to RFC 7519 (JWT) but to RFC 8259 (JSON).
I-JSON (i.e. Internet-JSON) mandates the uniqueness of claim names in an
object (as well as JWT).
RFC 8259 does not mandate uniqueness.
Denis
From JWT RFC 7519, section-4:
The Claim Names within a JWT Claims Set
contain an "iss" (issuer) claim ... The JWT
MUST contain an "status_list" (status list) claim ... Maybe, in the
future, this would be changed into: The JSON object MUST contain a
single occurrence of an "iss" (issuer) claim ... The JSON object MUST
contain at least
to use implementations that report all of
the name/value pairs, including duplicates.
Denis
From: https://www.rfc-editor.org/rfc/rfc8259.html#section-4
— Justin
On Oct 2, 2023, at 1:12 PM, Denis wrote:
The latest draft (i.e. draft-looker-oauth-jwt-cwt-status-list-latest)
which
ces||
||--->||
|Referenced Token||Status List Token|
| (JSON or CBOR token) || (JSON or CBOR token) |
||Describes Status||
||<---||
+------++--+
*
The first draft of the OAuth WG should rather be called:
*draft-oauth-status-list-t
ion to act as Big Brother,
i.e. allowing it to know where and when a token it has issued has been used.
Denis
I support adoption. I have questions about the specifics which I'll
try to write up in the next week or so, but the basic idea seems
useful. (The tl;dr of my thoughts is: have we learned
the rug.
Wouldn't "advanced cryptographic schemes" mentioned in the first method,
like BBS+ be more appropriate ?
When using BBS or BBS+, the same blinded link secret can be used since
only a zero-knowledge proof of knowledge of the link secret is demonstrated.
Denis
property between verifiers
and is not extensible to support the Unlinkability property between
verifiers ?
Should two different and incompatible models be developed by the IETF ?
Denis
PS. "The Commission is already investing €46 million from the Digital
Europe Programme in four large
e it would likely create a confusion with the OAuth 2.0 and OAuth
2.1 Frameworks
and this is one of the topics currently discussed in the SPICE BoF.
Would a Creds WG be more appropriate ?
Denis
Hi Roman,
I'm going to dodge some of the bigger picture questions but wanted to
give a bit of historical co
Hi Hannes,
Sorry for this late response. The SPICE BoF (and other activities) kept
me quite busy.
Hi Denis,
OAuth defines 4 roles, see Section 1.1 of RFC 6749.
A RO is a role supported by a (human) user.
In the three party model there is likely a human behind the holder as
well.
You
ady addressing this topic, e.g.,
W3C, OpenID, DIF (Decentralized Identity Foundation) and GlobalPlatform
(for the TEE).
The key question is: what the IETF should do (/or not do)/ in this area ?/
///
A BoF should be opened to continue this discussion.
Denis
Thanks for kicking off the conversation!
Inl
Hi Oliver,
On may 27, 2023, I sent an email to you, Lief and on the list and
(unless I missed it) I have not seen a reply to it.
A response would be appreciated. I copy and paste below the content of
that email.
Denis
Note : A "presentation of an SD-JWT VC" is different from a &
aken as a WG draft, the articulation between
user authentication and user authorisation should be addressed.
A side question is the following : will this draft be dealing with
identification and/or authorization ?
Denis
Thank you all for your feedback on this document.
The chairs would like
and user authorisation should be addressed.
A side question is the following : will this draft be dealing with
identification and/or authorization ?
Denis
Likewise!
Skickat från min iPhone
27 maj 2023 kl. 01:12 skrev Giuseppe De Marco :
Hi,
I support sd-jwt-vc with the will to contri
ce, the concern could be solved using no " advanced cryptographic
schemes " but by defining a new structure in the JWT that would allow
to associate a "sub" claim (as well as other claims) with a specific
Verifier. A change of the SD-JWT Releases structure should be considered.
T
ion has already been mentioned.
It would be nice to start to mention it, rather than to continue to omit
it. Do you see a better place to mention it ?
Denis
Thanks Denis, I agree the word "cannot" isn't quite right there. I
struggled with trying to find the right wording (mor
information than
strictly necessary about the authenticated user without the end user
being
able to know it. Such additional information may endanger the
privacy of the user.
Denis
I've published an -04. It has that very minor change. There was also
an off-list discussion during WGLC
for two independent signed JWTs
and for developers of verifiers to verify one independent signed JWT ?
If other words, what are the advantages and the drawbacks associated
with this approach ?
Denis
All,
Kristina and I would like to bring to your attention a new draft that
we have been working
Hi Hans,
Hi Denis,
thanks for correcting the thread topic:
On Tue, Mar 29, 2022 at 10:19 PM Denis wrote:
nothing stops Alice from logging in on Bob's device, obtaining
tokens for access and then leave Bob with the device, even in
long term user accounts
Even so, Alice
Hans,
Please do not mix topics. I have changed the title of that thread, for
not polluting the original one.
On Tue, Mar 29, 2022 at 9:54 PM Denis wrote:
Nothing stops Alice from giving her token that says “This is
Alice” to Bob and having Bob use it.
Such scenario does
Justin,
Denis,
This is why the use of “iat” and “nonce” are recommended, to prevent
this kind of replay, and these are already discussed in the draft.
Having a highly targeted request with narrow presentation window is
desirable in most cases, but some applications of DPoP do want to have
long-term
user accounts).
Denis
If the “legitimate” client willingly gives away its secrets and tokens
to the “illegitimate” client, then the latter isn’t actually
“illegitimate” anymore.
What I was saying is that the “attack" is not even necessary if the
clients are in fact w
The traffic between the clients is kept to the very minimum.
Denis
+1
Am 29.03.22 um 15:10 schrieb Justin Richer:
And this is exactly the problem with the “collaborating clients”
attack, as has been pointed out any number of times it’s been brought
up before. If two clients are willingly colla
that the token indicates "over 18". If the user is over 18 now,
he will certainly be "over 18" the next days, months or years.
There is no need to refresh the token as it would be the case if the
token included a home address.
Denis
Interesting, but won't two collaborating client
en transmitted voluntarily by a legitimate client
to an illegitimate client.
Denis
All,
As discussed during the IETF meeting in *Vienna* last week, this is a
*WG Last Call *for the *DPoP* document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Please, provide
Nikos,
You wrote:
I would like to prevent clients from sharing their access tokens.
Proof of access token possession using client secret is unable to
prevent clients from sharing their access tokens.
When two clients agree to collaborate, one client can perform all the
cryptographic
protections (or detection) features will be obtained
as well as which protections (or detection) features will not be obtained.
Let us wait to have both the security considerations section and the
privacy considerations section written,
before adopting this draft as a WG document.
Denis
Remember
of Section 6, as noticed by Murray.
Denis
Hi Denis, this aspect was debated at length (one example in
https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/
<https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/>,
there are many others) and the consensus ref
*guidance *is still there, but
the sentence with the "*MUST NOT*" has been removed.
Denis
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hi Rifaat,
One addition that may be useful:
Before the sentence: "Hannes: I was not aware of this work in ISO",
there is a sentence missing:
Denis: ISO/SC 27/WG 5 is just starting to work on PWI about age
verification. If you are a member of ISO / SC 27/ WG 5 you can
Hi Steinar,
Please read first the response just posted to Daniel.
Hi Denis, I don't understand the attack or the countermeasures you are
describing completely - but that doesn't really matter.
Since it does not matter, let us continue. :-)
As far as I know OAuth doesn't require a specific
update.
[Denis] I don't believe that the scenario is covered with the above
sentences.
I don't understand. This is not about believing, it is written very
clearly and conclusively in the text of the current draft.
We've had this discussion before, and, although irrelevant for the
meaning
Hi Daniel,
Denis,
I was awaiting your mail and I admire your perseverence with bringing
this topic to our attention.
[Denis] I admire your perseverence with constantly refusing to include
this attack. :-)
To your points:
Am 12.04.21 um 13:36 schrieb Denis:
The case where two clients
be discarded.
In this way, the access token will be linked to the user account of the
legitimate client and the illegitimate client cannot take advantage of
the claims
contained into the access token.
Denis
All,
The coming OAuth WG Interim meeting is this coming* Monday, April
12t
to these two emails and neither a
version 03.
Denis
All,
The coming OAuth WG Interim meeting to discuss DPoP is this Monday,
March 15 at 12:00pm *EDT*.
The following link has links to the slides and the draft, and will be
used to capture the notes and attendees:
https://codimd.ietf.org/notes-ietf
ery access token.
In your email you wrote:
I don’t see how moving from handing your creds over to a third party
to OAuth2 workflows, harms either privacy or security.
I hope that the facts mentioned above will allow you to see that OAuth
does harm the user's privacy.
Denis
Il 01/03/
ccesses to
one or more RSs).
The choice between these three options for the "sub" claim parameter
is managed by the AS.
However, if the AS supports a "scope" parameter in the access token
request, it is possible for the AS to define different scopes that
support one or m
following guidance in section 8.1 will then become unnecessary:
In order to guard against memory exhaustion attacks a server SHOULD
reject DPoP proof JWTs with unnecessarily large "jti" values or
store only a hash thereof.
Denis
On Thu, Dec 3, 2020 at 5:09 AM Neil Madden <
new DPoP proof JWT would very likely succeed for the second client.
In case of a collision, it would also be possible to return a specific
error code saying something like "duplicate iat/jti pair".
So the client would be informed that it should perform another attempt
using a new DPoP
in a "DPoP" access token, RSs are
unable to link the access tokens they receive. However, this method has
the disadvantage
to require the generation of a different key pair for every "DPoP"
access token. This may be time and resource consuming. When thi
8.2.DPoP private key usage
A legitimate client does not necessarily need to "have access to"
the private key that is being used to sign a DPoP proof JWT, but can
simply "use" the private key without knowing its value.
This means that it is able to perform cryptographic computations
either for its own benefit or for the benefit of other users. In the
later case, an illegitimate client may be given both an access token
and a DPoP Proof JWT by a legitimate client.The fact that a DPoP
proof JWT can only be used once does not protect against this
collaborative attack.
18. Currently there is no "Privacy considerations" section, whereas
there should be one.
This point is addressed in a separate email since it proposes new text.
Denis
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
an
simply be an identifier used during the time window which complements
the "iat" claim.
Using both the "iat" claim and a 32 bits pseudo-random number will be
quite sufficient. It is also has the advantage of using less memory and
it is easier to flush the entries looking at the 32 fi
Hi Brian,
Hi Denis,
The choice to use "iat" vs. "exp" was made in the summer of last year.
You can see some of the discussion from then in
https://github.com/danielfett/draft-dpop/issues/38
<https://github.com/danielfett/draft-dpop/issues/38>.
I believe it
a token is still usable and is unlikely
to get a rejection of the token
because of an unknown time window defined by a RS.
* The RS is able to manage better the "jti" claim values, because it
will be able to discard "jti" claim values
as soon as they are outsi
might be useful to add it, so that the above text can refer to it.
Denis
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
o uniquely identify the holder of the access token
are indeed be present inside an access token.
It might be useful to add it, so that the above text can refer to it.
Denis
Thanks Neil, this very much sums up my thoughts on this topic.
Since this has been mentioned in yesterday's call, I'l
ide an access token.
It might be useful to add it, so that the above text can refer to it.
Denis
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
:
Authors MUST describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
Denis
Hello Denis,
The most recent version of the DPoP draft is not
draft-fett
n the mailing list with Hannes on September 10:
[Denis] I believe, it would be worthwhile to add a sentence, just
after this sentence, with the following text:
When an authorization server decides to issue a JWT access token
compliant to this profile, then the following requirements a
is ineffective.
Denis
PS. The podcast is a nice effort but is far too long (29:37).
The mTLS vs DPoP was good in articulating how the two specs are alike,
how they differ and which particular type of app they are meant to serve.
I'm saying this as a person who is generally allergic to technical
Hi Hannes,
All my concerns about the fact that the OAuth 2.0 framework assumes that
access tokens are treated opaque by clients are now solved.
Thanks !
Hi Denis,
Thanks for the clarifications regarding the uniqueness properties of
the values that go into the subject claim.
Looking
Hi Hannes,
Thank you for responses. See below.
Hi Denis,
Hi Dick and Hannes,
1) While reading RFC 7519, no reader may be able to figure out that
there are more than two flavours of the "sub" claim.
This draft is introducing two new other favours of the semantics of
the "s
profile ?
Which parameter(s) allow it to ask an access token compliant to this
profile ? How can the AS know that it got a call for the issuance
of an access token compliant to this profile ?
Denis
We have gone through this discussion before. This document does not change the
underlyin
it got a call for the issuance
of an access token compliant to this profile ?
Denis
Denis
The objective of this document is to standardize the token the AS
shares with the RS. It is not to standardize how the client can read
the token. Just because the user is using the client, that does not
mean th
7519.
In the general case, an identifier can be:
1. locally unique in the context of the issuer (i.e. the same for all RSs),
2. globally unique (i.e. the same not only for all the RSs but also for
servers that have nothing to do with OAuth),
3. unique for an AS/RS pair, or
4. unique for each access tok
ndpoint is published by an
AS [RFC8414],
users and clients have no way to know whether the RS will be allowed
to use it, nor whether it will effectively use it.If these
implications are not acceptable,
users or clients should not use an AS that publishes an
introspection_endpo
Hello Dima,
Not exactly.
Change :
or by allowing the third-party application
into:
or by allowing the application
Denis
Thank everyone for your feedback.
So the abstract could look like this:
The OAuth 2.1 authorization framework enables a*n**third-party* application
to obtain
has no way to indicate that
he consents for making such a call).
As a conclusion, since draft-ietf-oauth-jwt-introspection-response harms
the user's privacy and fully by-passes the User consent,
this draft should not be progressed to the RFC level.
Denis
The "can" works better,
It would not be reasonable to say that
this concern is outside the scope of this draft.
Denis
This draft contains a "Privacy considerations" section (Section 9).
.
The content of this section is as follows:
The token introspection response can be used to transfer personal
iden
ion call has
been made and thus be able to make sure which client
has attempted perform an access to that RS and at which instant of time.
The use of this call allows an AS to track where and when
its clients have indeed presented an issued access token.
Denis
The IESG has received a request fr
This document does not include a "Privacy considerations" section, but
it should.
Denis
All,
This is a WGLC on the *Pushed Authorization Requests *document:
https://www.ietf.org/id/draft-ietf-oauth-par-03.html
Please, take a look and provide feedback on the list by *August 25th.
g behavior at a somewhat more granular
and specific level than would otherwise be possible in its absence.
Denis
Filip
Odesláno z iPhonu
10. 8. 2020 v 19:21, Aaron Parecki :
I agree that there is nothing unique to PAR that would justify adding
the privacy considerations mentione
a Privacy Considerations section to the OAuth 2.1 draft.
Denis
I didn't have the reference offhand during the meeting today but
https://tools.ietf.org/html/rfc6973 looks to be a good source of
considerations for writing privacy considerations. As I mentioned,
I've written a number of such sectio
nts.
IMHO, a token type would be able to easily address the problem;
otherwise sections 3 and 4 should be deleted.
The remaining of my replies are within the text below prefixed with [Denis].
Hi Denis,
Please see my response below.
*From:* Denis
*Sent:* Wednesday, June 3, 2020 12:12 PM
*To
Hi Benjamin,
My responses are between the lines.
Hi Denis,
On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote:
Hi Benjamin,
Responses are between the lines.
On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
Hi Benjamin,
On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote
ns that have been raised but which
have not yet been answered at this time:
* how can a client request a JWT compliant to /this/ profile, and
* how can a client be confident that it got a JWT compliant to /this/
profile ?
Denis
Let me try to jump in here in order to make a prop
name claim to be present in the JWT, unless an error
is reported, it can verify that these claims are indeed present in the JWT.
This is another reason why a client should be able to inspect the
content of the access token.
Denis
On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:
As indicated in the
Hi Benjamin,
Responses are between the lines.
On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
Hi Benjamin,
On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
Since then, I questioned myself how a client would be able to
request an access token that would be *strictly compliant
will have a deep knowledge of every
operation that can be performed by a user on every RS.
As a consequence, the AS would also be in a position to trace the
actions performed by its users on the resources servers.
Other approaches that are more "privacy friendly" should be considered
ith respect to the operations it is willing to perform on a RS.
As long as only the scope request parameter will be usable in an access
token request to select the claims to be placed
into an access token, it will not be possible to remove this strong
relationship.
Denis
__
Hi Benjamin,
On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
Since then, I questioned myself how a client would be able to request an
access token that would be
*strictly compliant with this Profile*.
I don't understand why this is an interesting question to ask. The access
token
is
allows to correlate principal activities across multiple resource
servers, while in addition, this globally unique identifier may also
allow to correlate the principal activities on servers where
no access has been performed by the principals to these servers but
where the same globa
to provide an answer ?
Denis
Denis, the change you mentioned is basically a typo, which I did fix
but did not publish a new draft for- that doesn’t change the substance
of the consensus (and is something that will be fixed in the
subsequent phases of the process).
Whether the sub should be mandator
ot; claim necessarily be present in the access token ?
If yes, this may be a privacy concern.
On the list there have been requirements for not making the "sub"
parameter mandatory.
This point needs to be addressed and solved one way or another.
Denis
All,
Based on the 3rd WGLC, we be
ser or if the format of the access token is not understandable
by the client, then the client SHOULD NOT forward the access token
to the resource server.
Denis
That text is an poor suggestion, Denis.
> end-user will usually have no knowledge of the attributes which
correspond to the scope
The O
-user would like to know which attributes have been placed in
a token before forwarding it to a resource server.
If these attributes do not correspond to the expectations of the
end-user or if the format of the access token is not understandable
by the client, then the client SHOULD NOT forwa
1 - 100 of 166 matches
Mail list logo
