[OAUTH-WG] Re: OAuth Digest, Vol 188, Issue 13

[Carl Cousino <[e-mail]>]

Help, unsubscribe


Thanks,

Carl Cousino

________________________________
From: [e-mail] <[e-mail]>
Sent: Tuesday, June 11, 2024 4:43 AM
To: [e-mail] <[e-mail]>
Subject: OAuth Digest, Vol 188, Issue 13

Send OAuth mailing list submissions to
        [e-mail]

To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
        [e-mail]

You can reach the person managing the list at
        [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."

Today's Topics:

   1. Re: Call for adoption - PIKA (Giuseppe De Marco)
   2. Re: Call for adoption - PIKA (Giuseppe De Marco)


----------------------------------------------------------------------

Message: 1
Date: Tue, 11 Jun 2024 10:25:14 +0200
From: Giuseppe De Marco <[e-mail]>
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
To: Richard Barnes <[e-mail]>
Cc: oauth <[e-mail]>
Message-ID:
        <[e-mail]>
Content-Type: multipart/alternative;
        boundary="000000000000f6c84e061a990124"

Hey Richard,

My reply was very verbose, thank you for the time spent in reading it.

The problem I see in the communities around the openid/ietf/any-other
technical specification is the way we use the term trust and how we aim to
achieve trust from a technical perspective.

I can show that my name is Giuseppe (subject id) and that you are talking
exclusively with me (secure cryptographic material exchange and
confidentiality in transaction) but this doesn't solve the problem we want
to solve through a trust establishment, because identity and key
attestations doesn't give us any trust.

As mentioned by Mike, OpenID Connect Core implementations already uses TLS
and subject id comparisons to achieve this.

The example of the surgery made with the chainsaw is something already
heard by architects that have implemented SAML2 and that reluctant to move
to OAuth 2.0. They said <<useless complexity>> or <<all those endpoints
only increases the attack surface>>.
Several years was spent to demonstrate why OAuth 2.0 was designed in a way
to satisfy several design principles about scalability and specialization
of the endpoints to specific functionalities.

I can only help, where needed or requested, to demystifying the complexity
of the relationships willing to find trust (in this context, at least, from
a technical pespective only) and be sure that who is going to create new
specifications is aware of the previous ones, of the problem that he's
trying to solve and recognize what is intentionally excluded from the scope.

I would like to continue this conversation with the will to merge the
openid federation approach and the PIKA that I see an important
specification to create a bridge to the X.509 world.
this also requires trust and reducing conflict between authors and
consequently between specifications I believe is an intrinsic goal of our
community.

If I had a little more time...

Il giorno mar 11 giu 2024 alle ore 05:09 Richard Barnes <[e-mail]> ha
scritto:

> Hi Giuseppe,
>
> To be blunt, solving the use cases we're talking about with OpenID
> Federation is like doing surgery with a chainsaw.  You might achieve the
> intended goal, but the results will be messy.
>
> The trust model we are addressing is one that already exists: A JWT is
> issued by an issuer identified by a URL, and the relying party needs to get
> keys that are verifiable associated with that issuer's URL.  The only thing
> we are doing is trading HTTPS for JWT signing for how that verifiable
> association is made.  It is explicitly *not* a federated model; X.509 is
> already baked into it and does the job well.
>
> Your first point is a good one, though.  It could be a good idea to have
> an indicator here of how the issuer intends the keys to be used (for
> issuing ID tokens vs. Verifiable Credentials, say).  Happy to have that
> filed as a first issue on an adopted document.
>
> Cheers,
> --Richard
>
>
> On Mon, Jun 10, 2024 at 6:50 PM Giuseppe De Marco <[e-mail]>
> wrote:
>
>> Hi,
>>
>> I appreciate the introduction of PIKA, which demonstrates a commitment to
>> addressing current challenges. However, I have identified some key areas of
>> concern that need attention:
>>
>> 1. The current documentation lacks clarity regarding the number and scope
>> of cryptographic keys, particularly in terms of their intended use across
>> different protocols. Given that an issuer can serve multiple roles, such as
>> an authorization server, a credential issuer, or a relying party issuing
>> signed request objects, it is important to consider the benefits of using
>> distinct, specialized keys for different protocols and roles and how PIKA
>> would propose a model to achieve this.
>>
>> 2. We already have a mechanism to bring multiple public keys, for
>> multiple scopes/protocols, in a chain of signed JWT. This is OpenID
>> Federation which doesn't depend to X.509 but at the same time is able to
>> distribute also X.509 certificates using the `x5c` claim within the jwk
>> claims and for legacy applications. I believe that this last point is
>> important, since I see X.509 as a requirement only for legacy applications.
>> I would not design a new infrastructure using X.509 as a foundamental
>> requirement for a trust framework.
>>
>> 3. I kindly suggest to clarify which is the meaning/intention of the term
>> trust, from which kind of perspective PIKA aims to approach the mechanisms
>> of the trust evaluations and for which trust topology (federative, end to
>> end, hybrid ...), the roles of the trust authorities or trusted third
>> parties and so on.
>>
>> 4. I read that PIKA reuses the same requirements of openid federation.
>> Probably this needs more clarifications. OpenID Federation provides a
>> mechanism to establish the trust to a subject and obtain its public keys
>> and not only this, since it allow a secure interoperability through a
>> secure metadata exchange and also the distribution of compliance assertions
>> called trust marks.
>>
>> 5. The trust model proposed in PIKA relies fundamentally on a WWW CA
>> (Certificate Authority) for purposes beyond its original design.
>> Specifically, assessing compliance with shared rules, such as a trust
>> framework or national regulations, falls outside the scope of WWW X.509
>> CAs. Consequently, using this type of binding to establish a higher level
>> of trust may not be appropriate. The use of the term "trust" in this
>> context could potentially be misleading. It would be beneficial to
>> reconsider the terminology and mechanisms used to better align with the
>> intended functions and limitations of the technologies employed.
>>
>> therefore,
>>
>> I would therefore suggest defining the terms trust and trust model, and
>> the purposes of the specification in relation to these.
>> Then list the problems that this specification intends to solve and the
>> requirements identified by it.
>>
>> If it is trust and the mechanisms for validating trust in relation to
>> common elements or properties between different entities (and mutual
>> recognition) we could start working on common elements already well
>> established in openid federation and that they could be further explored
>> with your contribution and requirements.
>>
>> From my side, I find the use of openid federation as a broad-based
>> solution evident. Today I am having a positive conversation with other
>> authors about the birth of two new drafts dedicated to openid federation
>> and I believe that this is a good time to join forces to build something
>> together with strong harmonizations, not just some endpoint picking.
>>
>> From my perspective Iam probably more interested in understand what
>> obstacles you have found in using federation and what additional features
>> or endpoints you intend to use to satisfy your requirements that, in fact,
>> I would mark with greater determination within the draft.
>>
>> Even If I read it with pleasure and curiosity, appreciating the work and
>> the effort spent of it, I look forward to receiving more information here
>> in this thread from the pika's authors.
>> Currently, I am hesitant to support this specification as it requires
>> additional time and comparative analysis before I can evaluate it
>> positively.
>>
>> Thank you for sharing and for the work made todate
>> Giuseppe
>>
>> Il giorno lun 10 giu 2024 alle ore 13:48 Rifaat Shekh-Yusef <
>> [e-mail]> ha scritto:
>>
>>> All,
>>>
>>> This is an official call for adoption for the *Proof of Issuer Key
>>> Authority (PIKA)* draft:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-barnes-oauth-pika%2F&data=05%7C02%7C%7C54d3061fd91e4e17f48c08dc89f2e049%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638536923438275130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yk0tWI9LVAgcs5xDwsOn7tn8YNg%2BDGeBTtl1vC3YcbQ%3D&reserved=0<https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/>
>>>
>>> Please, reply *on the mailing list* and let us know if you are in favor
>>> or against adopting this draft as WG document, by *June 24th*.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 9743 bytes
Desc: not available

------------------------------

Message: 2
Date: Tue, 11 Jun 2024 10:42:58 +0200
From: Giuseppe De Marco <[e-mail]>
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
To: Tom Jones <[e-mail]>
Cc: oauth <[e-mail]>
Message-ID:
        <[e-mail]>
Content-Type: multipart/alternative;
        boundary="0000000000006acf15061a9941ef"

Ciao Tom,

Public Key Infrastructure satisfies the requirements to provide public
keys. Technically, using X.509 certificates represents a consolidated
approach.
Giving public keys doesn't help in establishing the trust or fully proving
the compliance to shared rules, that's why openid federation authors insist
that openid federation is not only a pki.

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 controls a private cryptographic key is
similar to the weakness about the bearer tokens.
Therefore, for instance, in advanced ecosystems and implementation is
required to demonstrate the proof of possession of the tokens because
bearers alone are not secure enough. This is more complex but required in
the real wold.

The point is: what is trust, how to establish trust in the real world,
which are the technical layers that we should (even in a modular way) take
into account to achieve our goals. Do we have the same goals?
Don't stop working together, let's keep the conversation to achieve our
goals in an harmonic way.

Il giorno mar 11 giu 2024 alle ore 06:11 Tom Jones <
[e-mail]> ha scritto:

> 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
> problem of there own making. So let them fix their own mistakes.
>
> thx ..Tom (mobile)
>
> On Mon, Jun 10, 2024, 8:37 PM Watson Ladd <[e-mail]> wrote:
>
>> On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
>> <[e-mail]> wrote:
>> >
>> > We all know that TLS certificates are handled by platform layers used
>> by applications and not the applications themselves.  There is no code that
>> understands X.509 certificates in most applications that use TLS.  They are
>> not equivalent in complexity.
>> >
>> >
>> >
>> > The draft would require adding code directly understanding the
>> structure and fields of X.509 to applications using it.  Eliminate that,
>> and I’ll support adoption.
>>
>> I don't understand your proposal. An X509 certificate is the only way
>> to link a DNS name to a key at a given point in time as we can
>> leverage the Web PKI. Absent that, what do you do?
>>
>> Also, I'm not sure what you mean by platform layers. Many of them
>> expose a function to verify a signature with a key in an X509 cert or
>> verify a cert chain, even outside the context of TLS. Are there
>> particular ones that would have a problem you are concerned about?
>>
>> Sincerely,
>> Watson Ladd
>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 4226 bytes
Desc: not available

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]


------------------------------

End of OAuth Digest, Vol 188, Issue 13
**************************************