I completely agree that education of users is not an answer to any security
question.
Be the change you want to see in the world ..tom
On Thu, Aug 22, 2024 at 10:08 AM Watson Ladd wrote:
> Hello,
>
> I would like to point out that the issuer verifier problem still
> remains open, even given th
now.
Peace ..tom jones
On Mon, Sep 16, 2024 at 12:56 PM Michael Jones
wrote:
> I regret to have to report that the issues that I believe resulted in the
> first call for adoption failing, despite being discussed on-list and at
> IETF 120, have not been addressed in the specification
>
What, exactly is json encoding? It sounds like a python or java method.
Afaik json can be encoded in utf 8 16 or 32. But form encoding is limited
to ascii or even to base64url
.. Is that the point. Will GNAP specify one encoding?
thx ..Tom (mobile)
On Thu, Jul 9, 2020, 12:29 PM Justin Richer wro
ahh - thx - so that explains why RFC 6749 OAuth 2.0 is ambiguous on the
topic. I suspect that means that GNAP will take a dependency on 8259,
Peace ..tom
On Mon, Jul 13, 2020 at 8:34 AM Carsten Bormann wrote:
> On 2020-07-13, at 17:19, Tom Jones wrote:
> >
> > What, exactly i
I have concerns, similar to Orie's, about assertions. Like Orie, I would
like to see something like this approved, but it must be secure. The
following is the part of the draft that concerns me.
Therefore, the client generates a key (Client Instance Key) and
(platform specific) attestations to
You really need to make it clear that these are native not web.
Please point me to demo.
thx ..Tom (mobile)
On Wed, Jul 26, 2023, 2:32 PM Paul Bastian wrote:
> Hello Tom,
> The client attestation draft does not make any suggestions on the
> architecture but gives a general purpose mechanism ho
Right Philippe - there really is no way to create a secure client as a web
app. You would need access to the trusted execution environment, which is
not available.
..tom
On Sat, Aug 26, 2023 at 5:21 AM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:
> My responses inline.
>
>
> H
The security reason for exclusion of error codes and other information is
that the data helps the attacker subvert the app. I continue my attempt to
avoid helping the attacker.
thx ..Tom (mobile)
On Sat, Aug 26, 2023, 7:58 AM Dick Hardt wrote:
> Jaimandeep: Do I understand your objection to ado
You can write your code as strong as you wish. You cannot determine if the
code running in the computer is that code running unaltered. ..tom
On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros wrote:
> Thanks for taking the time to respond and for the constructive feedback.
>
> Still, there is som
is not secure enough for
>their responsibilities.
>
>
> S
>
> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :
>
>> Yes, but this is true for all flows. Web applications are dangerous.
>> Applications handling user input are dangerous too.
>>
>> Le d
+1 Denis.
I cannot understand why OAuth is used in this user (or many others in
development) as there is no authorization involved!
The verifier asks the user (wallet) for data (perhaps with some back and
forth) the user (wallet) supplies the data or not with consent to the
conditions supplied by
es sense to do so.
>
> Maybe a different way of gaining clarity on the same topic... If OAUTH
> were to recharter, what would it include / exclude... (ignoring the 3 party
> model for a second)... would attestaton be in scope?
>
> Regards,
>
> OS
>
>
> On Sat, Sep 9,
Kind of interesting to consider this to be a security consideration. It
depends on whose security is being considered. I have always thought that
the only way for the subject to approach a request for data is as a privacy
threat. The attacker is the "client" every time. Sometimes it is something
at
Attackers do not stick to the rules. It sounds to me like one of the
security considerations for any standard that employs json, or any other
structured data language, is to ensure that the input is validated to be
compliant. I have been in the position of trying to enforce type checking
on experie
That's leaking the existence of PII. That requires permission of the
subject. I think it's way more complicated than you think.
thx ..Tom (mobile)
On Tue, Oct 17, 2023, 6:20 AM Orie Steele wrote:
> Hello,
>
> In government documents that feature redaction, it's common for the
> redaction to be
It makes sense to me that the sub should always be the subject of an issued
token.
thx ..Tom (mobile)
On Sun, Oct 29, 2023, 7:54 PM Justin Richer wrote:
> I disagree with the utility of just "sub" here. The subject of the token
> is always contextual to the issuer of that subject - however, the
This sounds like an attempt to re-enable 3rd party cookies.
Are you seriously considering allowing access to a user's camera from one
client to another w/o user consent?
This is the sort of stuff that gives the web a bad name!
..tom
On Tue, Nov 14, 2023 at 10:20 AM Atul Tulshibagwale wrote:
> I
I agree with Mike. This exercise seems to add confusion rather than clarity.
thx ..Tom (mobile)
On Tue, Nov 28, 2023, 10:05 AM Michael Jones
wrote:
> Orie, you wrote:
>
>
>
> TLDR; TallTed believes that the convention in the JWT BCP is not correct:
>
> https://datatracker.ietf.org/doc/html/rfc8
JWT
>
> Secevents or a JWT credential might define parameterization. For example,
> a credential might describe itself as having particular types/profiles of
> claims about a subject, such as being usable as a driving license and as a
> primary government-issued identification.
>
>
Pronounce jwt as tho it were a Welsh word. It comes out close. More like
joot
thx ..Tom (mobile)
On Thu, Jan 11, 2024, 6:53 PM RFC Errata System
wrote:
> The following errata report has been rejected for RFC7519,
> "JSON Web Token (JWT)".
>
> --
> You may re
The big problem is that standards bodies all over the spectrum are creating
attestations without even bothering to see what is happening in other
communities. The verifier will have many attestations to choose from and
will thus choose to do nothing with any of them. Perhaps it is time to ask
a ver
al carries the
> status.status_attestation object this is the element that gives to the RP
> the hint to looks in the vp_tokens for the status attestation.
>
> and they all lived happily ever after, please help me find some problem
>
>
> --
> *Da:*
Proof seems to be yet another term for which we already have other terms.
Can anyone explain the difference between:
proof
presentation
evidence.
..tom
On Fri, Jan 19, 2024 at 4:28 AM Denis wrote:
> Hi Giuseppe,
>
> Ciao Denis,
>
> Thank you! By points.
>
> First, I still have a vocabulary pro
texts. . (like
proof -> a cryptographic ability that is verifiable)
Perhaps you don't care that these are incorrect uses of the word?
..tom
On Fri, Jan 19, 2024 at 10:46 AM wrote:
> You present evidence as proof.
>
>
> On 2024-01-19 12:50, Tom Jones wrote:
>
>
> Proo
; Best
>
> Don
>
> And for the record I am not a technologist. I am a person who tries to
> solve business problems.
>
>
>
> On 2024-01-21 11:08, Tom Jones wrote:
>
> yes - i see that's what you are doing and think it is not only wrong, but
> misleading.
&g
it is far from
complete.
https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme
..tom
On Sun, Jan 21, 2024 at 1:03 PM Tom Jones
wrote:
> Technically oauth is about authorization not authentication. And
> technically attestation is provided by rats a
't process VCs, their
> computers do. (Hence the terminology of User Agent, not user, in the
> W3C)
>
>
>
> On Sun, Jan 21, 2024 at 4:46 PM Tom Jones
> wrote:
> >
> > I should have added - if you get a verifiable presentation from a wallet
> with a verifi
gt; required.
>
> Key binding is basically the secured version of a W3C VP, but restricted
> to a single credential, instead of multiple credentials.
>
> Key binding is not required afaik.
>
> Therefore presentation can be forwarded / reused.
>
> OS
>
> On Tue, Jan
The whole thing is pointless as the client owner (as opposed to the subject
for which client status is requested) can just define the instances to be
the same. There can be no way to attest to the validity of such an
assertion.
thx ..Tom (mobile)
On Fri, Jan 26, 2024, 10:42 AM Justin Richer wrot
I think the proposal should be renamed as optimized data mining. AIs around
the world will love the idea. Herd privacy is utter nonsense and has been
from the beginning.
On Tue, Feb 6, 2024, 5:08 AM Denis wrote:
> Comments on draft-ietf-oauth-status-list-01.txt
>
> The text states:
>
> *11.* *Pr
Not sure if techies care, but that really needs to be a four party
transaction where the subject of a credential may not be the holder of the
device where the credential is held. Your are thereby excluding
appropriately 15% of humanity. This is, frankly, unconscionable and you
must accommodate all
So now we are proposing types of types of types of data elements. I feel
really bad about this as I introduced the first semantic tag into EDI back
in the 1980s. I can't believe it has come to this. I can't believe that
anyone imagines giving this sort of specification to different programmers
and
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 cancelation of the person. Some that violates the
fundamental rights of human beings. Revocation is basically discrimination.
thx ..To
Y'all are missing another option. (re Sam's Comments)
The user is given a user agent to use on their own device when accessing
enterprise data.
I know of two that are shipping today. https://www.getprimary.com/
Now it is possible to access other sites with these browsers as well - in
fact they spec
Right. Google treats email as a guid for user name. Any old guid should
work.
thx ..Tom (mobile)
On Sat, May 11, 2024, 3:22 PM Dick Hardt wrote:
>
>
> On Wed, May 8, 2024 at 4:07 PM Sam Goto
> wrote:
>
>> That's easier to answer: the browser needs name/email/picture to
>> construct an account
Has anyone considered what information the RP verifier should supply for
FedCM to function well on the behalf of both the verifier and the user?
thx ..Tom (mobile)
On Thu, May 9, 2024, 8:06 AM Dick Hardt wrote:
> The NASCAR problem is rooted in the RP does not know which provider(s) the
> user
/1n7HobJ6QTsNld5rn1uuIiNw0A__L44ug/edit?usp=sharing&ouid=109794657323597753486&rtpof=true&sd=true
..tom
On Thu, May 9, 2024 at 10:01 AM Sam Goto wrote:
>
>
> On Thu, May 9, 2024 at 9:07 AM Tom Jones
> wrote:
>
>> Has anyone considered what information the RP verif
Question - how does all this interact with the password manager?
Can the RP ask if they have an entry in the PM first? Or is that too much
of a privacy issue?
Also when calling for an app, wouldn't it matter if the app were web vs
native?
Which one does this thread discuss? ..tom
On Tue, May 21,
This whole problem did not need to happen. When the federation spec was
being created I asked them not to deviate unnecessarily from pki. But the
very guys that are on this thread told me that they were not a pki and so
there was no reason for them to follow existing rules. This is entirely a
probl
>
>>>>> TLS is not removed, we use X.509 based pki on the web, therefore also
>>>>> using federation.
>>>>>
>>>>> TLS is used to establish confidentiality with an endpoint,
>>>>> establishing trust to a subject only because it c
I am utterly appalled by this statement
" opaque value, OAuth implementors usually don't sanitize the value."
No web site should ever use any data from the user's device without full
validation as it is *completely untrustworthy*.
Treating this head value differently than any other header value is
I have opposed channel-binding or token-binding from the beginning as they
serve very different puppies and typically fall under different management
within large enterprises. I have tried to push for a simple way to test the
validity of a signature for decades into the future as that is typical fo
There are many cases of verifiers colliding with issuers.
Police recording all traffic stops looking for patters of abuse.
One time time and similar use restrictions on tokens.
Patterns of use that indicate fraud or abuse of financial or tracking by
third parties.
Password or vendor relations apps.
that doesn't answer the question about users randomly selecting some to
store and some to reject. This seems to me like user private information.
As is most of the feedback to the issuer from the wallet.
Peace ..tom jones
On Sat, Sep 21, 2024 at 7:30 AM Daniel Fett wrote:
> Hi Dick,
&
As I tried to make clear in an earlier post - there is no such thing as a
TLS cert. Various attributes MUST be included in TLS certs and that
combination is well known and easy to request.
thx ..Tom (mobile)
On Wed, Sep 18, 2024, 12:44 PM Michael Jones
wrote:
> Hi Richard,
>
>
>
> We clearly ha
es of the PKI for the actual purpose of the
key and cert.
Peace ..tom jones
On Tue, Sep 17, 2024 at 1:01 PM Vladimir Dzhuvinov
wrote:
> I frankly don't see how the central premise of PIKA - the reliance on a
> TLS web domain certificate - can be made to work in practice.
>
>
>
So - what trust infrastructure "needs to exist". That's a real question
that deserves a real answer. Not clear who has the smarts and authority to
do that.
Peace ..tom jones
On Thu, Dec 26, 2024 at 10:08 AM Pierce Gorman
wrote:
> What mechanism(s) are you referring to that
This problem was clearly demonstrated by the California mDL hackathon where
the default presentation was ALL DATA. That is the easiest path, so it
remains the one most taken. We have known since standards were first
introduced that they immediately create a drive to the bottom. This will be
the fat
I am appalled!
All humans must adapt to the consent plans of this small standards group!
I for one do not plan to adapt - sorry about that!
Peace ..tom jones
On Thu, Dec 26, 2024 at 4:15 PM David Waite
wrote:
>
>
> > On Dec 26, 2024, at 10:38 AM, Tom Jones
> wrote:
> >
admirable, but
there are no UX people involved in the discussion.
Peace ..tom jones
On Wed, Dec 11, 2024 at 5:01 PM Watson Ladd wrote:
> Dear all,
>
> I'd like to propose the following edit to resolve the concerns I have
> around endorsing dangerous applications of SD-JWT:
&g
not
be used for other purposes without the person's consent.
Clearly information holders can do what they want with their own data.
Peace ..tom jones
On Mon, Dec 16, 2024 at 11:22 AM Pierce Gorman
wrote:
> I think I disagree. I assume an SD-JWT in a VP could be volunteered by a
in OID4VP. In that case the
selective disclosure will be irrelevant as the means to disclose the
selection will be inadequate. So the SD-JWT may well technically work, but
the first use will be fraudulent as the selection will not be by informed
user consent.
Peace ..tom jones
On Tue, Dec 17, 2
> for one purpose to the police for another? This would legally not work
>
>
>
> *Von:* Tom Jones
> *Gesendet:* Dienstag, 17. Dezember 2024 02:26
> *An:* Pierce Gorman
> *Cc:* pe...@acm.org; IETF oauth WG
> *Betreff:* [OAUTH-WG] Re: SD-JWT linkability
>
>
>
&
don't release the ID number.
Peace ..tom jones
On Tue, Dec 24, 2024 at 6:34 AM Watson Ladd wrote:
> I see that people are uncomfortable with making any mandates, and so I've
> tried to be purely descriptive in this proposal. I leave it to the WG to
> decide where to put it, but
if by ID you mean ID number - then it is a tracking number.
Isn't it super obvious - why are we pretending to be privacy enabling?
Peace ..tom jones
On Tue, Dec 24, 2024 at 10:15 AM Wayne Chang wrote:
> Tom, how do you feel about private sector issued ID?
>
> Best,
> Wayn
binding to the holder.
That would be a good thing - but the only way I know involves trusting the
telco - which we all know is a dead end.
What other mechanism can bind the holder to the device w/o the telco (or do
we just nationalize the telcos again.)
Peace ..tom jones
On Tue, Dec 24, 2024 at
56 matches
Mail list logo
