[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

Hi David and Vladimir,

We discussed this in the WG session in Vancouver.  The aim here is
certainly not to just take the certificate on the web server and re-use
it.  Rather, we are re-using the underlying PKI.  As I said in YVR and in
my response to Mike just now, we should have separation between web server
certificates and PIKA-signing certificates.  My view is that a prefix is
sufficient ("_pika.example.com").  We could discuss things like EKUs, but
those will be harder to deploy.

In any case, there are solutions here, so I would propose we adopt the
document and then discuss which solution is best.

--Richard


On Tue, Sep 17, 2024 at 6:29 PM David Waite  wrote:

>
>
> On Sep 17, 2024, at 1:58 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.
>
>
> Reasons: Infrastructure in the real world, mixing of concerns, conflict
> with CA policies and CAB Forum requirements, NIST etc guidance compliance
> issues.
>
> I agree with Vladimir unfortunately.
>
> A certificate is a bundle of restrictions, but the two most critical are
> on subject name and purpose. This reuses a certificate meant to secure
> network traffic with a particular DNS name to one securing arbitrary
> application messages from a particular origin.
>
> This would not only break a lot of organizational security policies (and
> potentially conflict with how they deploy their network infrastructure),
> but ignores CA policy that is baked into the TLS certificate.
>
> -DW
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

Hi Mike,

We addressed these points in the presentation in YVR, where we had a
successful IRL adoption call based on the premise that these could be
worked in the WG post-adoption. You were in the room for that, so I'm
surprised that these concerns are being re-raised now.  The chairs advised
us not to revise the draft before we confirmed that adoption call on the
list.

Nonetheless, here's a quick recap of what we said in YVR:

1. Application-level use of PKI -- Several developers have opined on-list
that this is not a practical barrier, and that the resilience benefits of
PIKA are worth the extra effort.

2. Reuse of keys -- The core idea here is to make PIKA signing certificates
different from certificates you would use on a web server.  For example, we
can require that the PIKA signing certificate use a prefix, say containing
a SAN for _pika.example.com when authenticating the issuer URL <
https://example.com>.

3. Authorities with paths not secured -- Paths are not secured today, with
HTTPS-based discovery.  Anyone who controls the domain on which an issuer
is hosted can impersonate that issuer.  PIKA is not making any change in
that regard.

4. Odd hybrid -- I'm not sure how to respond to "odd" as an engineering
concern.  JOSE and X.509 have been intermixed since the "x5c" parameter was
introduced.  The layering here is actually quite clean: JWK and X.509 talk
about different keys, with the X.509 keys "blessing" the JWKs.

5. Upgrade path -- There is a trade-off here between concreteness and
future-proofing.  Our proposal is to continue to have PIKA articulate a
concrete, PKI-based mechanism, but also provide some notes on how one would
update it to use different authority mechanisms.

As to the direction of travel: The direction this document is trying to
move is orthogonal to the axis you're talking about.  The OAuth ecosystem
already relies on X.509 in the ways we are relying on it here.  We are just
expressing that reliance in JWS instead of HTTPS.  If, in the future, the
OAuth ecosystem relies more on JWS in the places it currently uses X.509,
we can make a PIKAv2 that takes that up.  But that is not the world we live
in today.

Best,
--Richard

On Mon, Sep 16, 2024 at 6:23 PM Michael Jones 
wrote:

> Hi Richard.  Thanks for the quick response.
>
>
>
> What surprises me is that a lot of substantive feedback was communicated
> during the prior call for adoption and as far as I can tell, none of the
> problems identified were corrected in the draft before the second call for
> adoption.  Incorporating it could have both solved the real problems
> identified and likely increased working group consensus.
>
>
>
> I would really appreciate it if you could send a reply to my note saying *
> *how** you plan to address each of the points raised – certainly the 5
> main points but possibly also the 6th bonus point “direction of travel”.
>
>
>
> Again, none of this feedback is new.  It’s a synopsis of issues that you
> were already aware of from the first call for adoption.
>
>
>
>         Thank you,
>
> -- Mike
>
>
>
> *From:* Richard Barnes 
> *Sent:* Monday, September 16, 2024 2:10 PM
> *To:* Michael Jones 
> *Cc:* Rifaat Shekh-Yusef ; oauth 
> *Subject:* Re: [OAUTH-WG] Re: Call for adoption - PIKA
>
>
>
> Hi Mike,
>
>
>
> This is a call for *adoption*, not a WGLC.  Our thinking was that these
> were fine problems for the WG to work on.  The adoption question is whether
> we believe the WG will succeed at that, i.e., whether we pretty much know
> how to solve the problems.  As your email points out, there have been a
> bunch of good discussions about these problems, and broad agreement on
> solutions.  We will get a draft out in time for Dublin with a first pass at
> getting them reflected in text.
>
>
>
> But resolving these problems should not be a blocker to adoption.
>
>
>
> Thanks,
>
> --Richard
>
>
>
> On Mon, Sep 16, 2024 at 3:55 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
> <https://www.ietf.org/archive/id/draft-barnes-oauth-pika-01.html>.  I did
> have a productive conversation with Richard in Vancouver, which resulting
> in him mentioning some of the problems in his presentation
> <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>.
> Here are the problems that have not been addressed since the first call for
> adoption:
>
>
>
>1. *Application-level use of PKI t

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

Hi Tom,

This draft is not about user proofing.  It's about authenticating the
issuer of a JWT.

--Richard

On Tue, Sep 17, 2024 at 7:57 PM Tom Jones 
wrote:

> This is not the way I used PKI for user proofing.  For convenience we
> added the Subject Alternative Name (SAN) which I guess is what you mean by
> a TLS certificate. This cert key was added to the TPM and used to sign JSON
> messages from the client to the server.
>
> Please don't mix the attributes 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 <
> vladi...@connect2id.com> 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.
>>
>>
>> Reasons: Infrastructure in the real world, mixing of concerns, conflict
>> with CA policies and CAB Forum requirements, NIST etc guidance compliance
>> issues.
>>
>>
>> The argument - JWKs are already published at an HTTPS URL - so let's take
>> the private key from the web reverse proxy (assuming there is no HSM) and
>> start signing JWTs at some application with it - how I would be able to
>> make this argument at some company X.
>>
>> When we look at how infrastructure is setup and administered - even if we
>> here in the OAuth WG decide to say "using the private TLS key for other
>> purposes is entirely okay" - there are significant practical issues with
>> this. It's not just a matter of being theoretically able to cross from the
>> app layer into the TLS layer. These two layers are typically managed by
>> different departments in orgs, and there are good reasons to isolate them.
>> I can't imagine being able to go to the admins and say, make me a copy of
>> the private key so I can sign JWTs with it, or let me install this service
>> on your infra to sign my JWTs.
>>
>> Let's also think about the potential legal and compliance issues.
>>
>> CAs that issue certs that prove web domain control have policies. These
>> policies are linked to the EKU values in the certs. Using the cert to sign
>> stuff other than that expressly identified in the CA policy and the
>> extKeyUsage fields can be seen as breaking those policies.
>>
>> https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf
>>
>> 3.6 Installation and Use of Your Certificate
>>
>> The purpose of Your Certificate is to authenticate and encrypt Internet
>> communications.
>>
>> I'd also suggest to go and check whether the CA / Browser Forum, in its
>> "Baseline Requirements for the Issuance and
>> Management of Publicly‐Trusted TLS Server Certificates" does not
>> stipulate an overarching policy for CAs that generally prohibits issue of
>> TLS certs with additional EKU values.
>>
>> Orgs that seek compliance with NIST and similar guidance are likely to
>> see issue with this approach too. Documents like NIST Special Publication
>> 800-57 / Recommendation for Key Management.
>>
>> I'm not in favour of adopting this spec as it is in the WG. Let's
>> consider the practical situation apart from what seems technically possible.
>>
>> I made a diff between drafts 01 & 02 and noticed that in 02 the policy
>> issues of using CA TLS certs for PIKA were probably recognised to some
>> degree, in the "5.2. Signing Key Compromise" section.
>>
>>
>> https://author-tools.ietf.org/iddiff?url1=draft-barnes-oauth-pika-00&url2=draft-barnes-oauth-pika-01&difftype=--html
>>
>> Apart from the "5.2. Signing Key Compromise" section, draft 02 that is
>> now proposed for adoption is identical to the original 01 that wasn't
>> adopted in June. It's okay to explain the intent to resubmit without
>> changes, just as it's okay to disagree on a particular adoption. I get it
>> that the topic of PIKA feels contentious.
>>
>>
>> Vladimir Dzhuvinov
>>
>> On 03/09/2024 13:47, Rifaat Shekh-Yusef wrote:
>>
>> All,
>>
>> As per the discussion in Vancouver, this is a call for adoption for the 
>> *Proof
>> of Issuer Key Authority (PIKA) *draft:
>> 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 *Sep 17th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

Hi Mike,

This is a call for *adoption*, not a WGLC.  Our thinking was that these
were fine problems for the WG to work on.  The adoption question is whether
we believe the WG will succeed at that, i.e., whether we pretty much know
how to solve the problems.  As your email points out, there have been a
bunch of good discussions about these problems, and broad agreement on
solutions.  We will get a draft out in time for Dublin with a first pass at
getting them reflected in text.

But resolving these problems should not be a blocker to adoption.

Thanks,
--Richard

On Mon, Sep 16, 2024 at 3:55 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
> .  I did
> have a productive conversation with Richard in Vancouver, which resulting
> in him mentioning some of the problems in his presentation
> .
> Here are the problems that have not been addressed since the first call for
> adoption:
>
>
>
>1. *Application-level use of PKI trust chains.*  As I wrote in my
>response to the first call for adoption
>,
>“Other than for TLS certificates, the OAuth and JOSE specs generally
>steer clear of dependence upon X.509 certificates.  Especially for a spec
>focused on JWK Sets, it’s odd to require an X.509 certificate to secure
>them.”  This problem is acknowledged in Issue 1 of Slide 7 of Richard’s
>presentation
>
> .
>As I also wrote
>,
>“application-level X.509 … is an anachronism that OAuth and JOSE have
>moved away from”.
>2. *Reuse of keys intended for one purpose for a different purpose.*
>PIKA uses WebPKI keys for signing things that are not Web resources.  Key
>reuse is not a good security practice.  This problem is acknowledged in
>Issue 2 of Slide 7 of Richard’s presentation
>
> 
>.
>3. *Authorities with paths not secured.*  In OAuth, authorities such
>as issuers can have a path component in their URL.  But the spec says “The
>contents of this field *MUST* represent a certificate chain that
>authenticates the domain name in the iss field” – meaning that the path
>component of the issuer is not secured.
>4. *Odd hybrid of JWKs and X.509.*  The spec uses both JSON Web Keys
>and X.509 certificates in the trust evaluation, which is an odd intermixing
>of technologies with overlapping purposes.  Architecturally, it would be
>cleaner to go all in on one or the other.  This is evident in Slide 5 of 
> Richard’s
>presentation
>
> 
>.
>5. *Upgrade path not defined.*  As Slide 7 of Richard’s presentation
>
> 
>says, “Need to make sure that systems using PIKA have a clear
>upgrade/interop path to alternatives to application-level certificates
>(e.g., OpenID Federation)”.  This is a point that I know John Bradley made
>to Richard in person in Vancouver.  This problem is not addressed in the
>specification.
>
>
>
> I’m also personally uncomfortable with the *direction of travel* embraced
> by this specification.  For over a decade, we’ve been consciously working
> to move OAuth away from X.509 and towards JOSE and this specification goes
> in the opposite direction.
>
>
>
> As documented above, these problems were discussed and acknowledged.
> Therefore, it’s disappointing to me that the updated draft didn’t address
> these previously identified issues.
>
>
>
> Therefore, I believe this specification should not be adopted, as the
> problems that caused it to not be previously adopted have not been
> addressed.
>
>
>
> Sincerely,
>
> -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef 
> *Sent:* Tuesday, September 3, 2024 3:47 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Call for adoption - PIKA
>
>
>
> All,
>
> As per the discussion in Vancouver, this is a call for adoption for the *Proof
> of Issuer Key Authority (PIKA) *draft:
> 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 *Sep 17th*.
>
> Regards,
>  Rifaat & Hannes
> _

[OAUTH-WG] Re: We cannot trust Issuers

[Richard Barnes]

I would observe that any solution based on garden-variety digital signature
(not something zero-knowledge like BBS / JWP) will have problems with
issuer/verifier collusion.  One-time tokens and batch issuance don't help.
There is no such thing as SD-JWT with issuer/verifier collusion
resistance.  At best you could have SD-JWP.

I don't think this needs to be a blocker on SD-JWT.  There are use cases
that don't require issuer/verifier collusion resistance.  We should be
clear on the security considerations and warn people away who care about
issuer/verifier collusion resistance, and accelerate work on SD-JWP if
that's an important property to folks.

--Richard

On Mon, Jul 22, 2024 at 7:25 PM Watson Ladd  wrote:

>
>
> On Mon, Jul 22, 2024, 3:30 PM John Bradley  wrote:
>
>> I agree that single-use proof keys and batch issuance are a must.
>>
>> Issuer verifier collusion is admittedly a problem.   To address that we
>> do need different cryptographic methods.
>>
>> MDOC also has the same issue.
>>
>> We should document the risk, but short of stopping EUID and mobile
>> driver's license deployment, we have limited options.
>>
>
> The problem only appears when the drivers license or EUID is used in a way
> that makes the user think their data is private. You don't have to support
> UX that lies to the user.
>
>
>> Hopefully, we can make quick progress on JWP.
>>
>> John B.
>>
>> On Mon, Jul 22, 2024 at 2:14 PM Watson Ladd 
>> wrote:
>>
>>> Dear Oauth,
>>>
>>> I'm disappointed to see SD-JWT work continue with inadequate privacy
>>> considerations. The fact is an Issuer can link any showings to
>>> issuance of the credential. This is not foregrounded sufficiently in
>>> privacy considerations, nor do we discuss how to ensure users are
>>> aware. We really need to use more RFC 2119 language and highlight
>>> these issues. Section 11.1 about local storage which has never been an
>>> IETF concern before is far more prescriptive than 11.4, and that's not
>>> a good thing. To be clear, the threat model must include an issuer
>>> that is a government issuing credentials that if used to verify age on
>>> certain websites or via a digital wallet on site, and learned about by
>>> the issuer who may have access to data from the site, will result in
>>> imprisonment or execution. This is not a hypothetical scenario.
>>>
>>> Users and UX designers will have intuitions that do not match the
>>> reality and that result in bad decisions being made. That's on us. A
>>> driver's license doesn't leave a trace of where you showed it, but the
>>> SD-JWT does.
>>>
>>> At a minimum I think we mandate batch issuance and one time usage
>>> using RFC 2119 language. We need to say in clear, unambiguous English
>>> that this mechanism enables an issuer to connect every presentation of
>>> a credential to the issuance.
>>>
>>> Sincerely,
>>> Watson Ladd
>>>
>>> --
>>> Astra mortemque praestare gradatim
>>>
>>> ___
>>> OAuth mailing list -- oauth@ietf.org
>>> To unsubscribe send an email to oauth-le...@ietf.org
>>>
>> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Fwd: New Version Notification for draft-barnes-oauth-pika-01.txt

[Richard Barnes]

Hi OAuth folks,

Thanks to everyone for the discussion on the adoption thread for this
draft.  This revision is mostly unchanged, except that we added a few notes
about risks related to compromise of web servers that hold certificates
that could be used to issue PIKAs.

--Richard


-- Forwarded message -
From: 
Date: Mon, Jul 8, 2024 at 6:32 PM
Subject: New Version Notification for draft-barnes-oauth-pika-01.txt
To: Richard L. Barnes , Sharon Goldberg 


A new version of Internet-Draft draft-barnes-oauth-pika-01.txt has been
successfully submitted by Richard Barnes and posted to the
IETF repository.

Name: draft-barnes-oauth-pika
Revision: 01
Title:Proof of Issuer Key Authority (PIKA)
Date: 2024-07-08
Group:Individual Submission
Pages:11
URL:  https://www.ietf.org/archive/id/draft-barnes-oauth-pika-01.txt
Status:   https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/
HTML: https://www.ietf.org/archive/id/draft-barnes-oauth-pika-01.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-barnes-oauth-pika
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-barnes-oauth-pika-01

Abstract:

   A relying party verifying a JSON Web Token (JWT) needs to verify that
   the public key used to verify the signature legitimately represents
   the issuer represented in the "iss" claim of the JWT.  Today, relying
   parties commonly use the "iss" claim to fetch a set of authorized
   signing keys over HTTPS, relying on the security of HTTPS to
   establish the authority of the downloaded keys for that issuer.  The
   ephemerality of this proof of authority makes it unsuitable for use
   cases where a JWT might need to be verified for some time.  In this
   document, we define a format for Proofs of Issuer Key Authority,
   which establish the authority of a key using a signed object instead
   of an HTTPS connection.



The IETF Secretariat
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

OpenID Discovery already allows this attack.  Its security relies on HTTPS,
which only authenticates the domain name.  So the owner of a domain can
present a valid discovery document with arbitrary information in it for any
issuer path on the domain.

Do you have the same concern with that mechanism?

On Tue, Jun 25, 2024 at 5:53 PM Michael Jones 
wrote:

> The other critique I voiced of the approach is that the application-level
> X.509 certificate can be used to secure the HOST part of the issuer, but
> not the entire issuer, since in general, the issuer will contain a PATH.
> Yes, the service hosting the issuers controls all the paths, as Richard
> replied earlier, but it’s not the service who is the attacker that this
> enables.  The attackers that not securing the PATH enables are the tenants
> themselves.
>
>
>
> An attacker could host a tenant at the service and get an X.509
> certificate securing the HOST part of its issuer.  However, because a
> legitimate tenant at another path shares the same HOST, the attacker can
> copy its X.509 certificate chain and utilize a substitution attack to make
> unauthorized statements about the victim tenant – statements that were not
> made by the hosting service.
>
>
>
> This attack was not addressed, and I believe is intrinsic to the decision
> not to protect the entire issuer value.
>
>
>
> I believe that adopting this draft would result in this attack occurring
> in practice.
>
>
>
> Thank you,
>
>     -- Mike
>
>
>
> *From:* Richard Barnes 
> *Sent:* Tuesday, June 25, 2024 1:56 PM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* [OAUTH-WG] Re: Call for adoption - PIKA
>
>
>
> Hi all,
>
>
>
> Replying to the top of the thread again to recap the arguments so far.
> (Hoping the chairs will give us a moment more to discuss before calling
> cloture.)
>
>
>
> It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t.
> the X.509-based mechanisms in the current draft.  In particular, we're all
> developers of relying party software, and it seems like we're all OK with
> doing X.509 (contra Mike's point about application-level X.509).
>
>
>
> If I understand Mike and Giuseppe correctly, they want to be less
> prescriptive about how the PIKA signer establishes their authority for an
> "iss" value, so that an OP could use some other mechanism (e.g., OpenID
> Federation).  It sounds like Mike at least is OK with the draft aside from
> this point.
>
>
>
> I would be open to adding some optionality in the authority mechanism
> here, but I'm wary of losing the concrete interop that we get with the
> draft as it is.  So we would need at least a strong recommendation for
> X.509, even if something else can be used if the parties agree to it.  I
> would be more comfortable doing something along the lines of what Rohan
> suggests, namely defining a concrete, X.509-based thing here, and extending
> it to support other mechanisms via follow-on specs as needed.  If there
> were a single additional mechanism that people wanted, as opposed to a
> generic "[insert authority mechanism here]", that would also be more
> palatable to me.
>
>
>
> Additional feedback would be useful on a couple of points:
>
>
>
> 1. From RPs: Is the X.509 requirement onerous to you?  Or is there enough
> library support out there that it's not a big deal?
>
> 2. From OPs: Is signing using a key bound to an X.509 certificate workable
> for you?  Or do you need some other authority framework?
>
> 3. From everyone: Is the general mechanism here useful, assuming we can
> align on some set of authority frameworks?
>
>
>
> Thanks,
>
> --Richard
>
>
>
>
>
> On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> All,
>
> This is an official call for adoption for the *Proof of Issuer Key
> Authority (PIKA)* draft:
>
> 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 -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

Hi Giuseppe,

Asking whether a technology addresses real-world challenges is a fair
question.  The point of the current draft is that we have empirical
evidence that X.509-based authentication works well for many cases, given
the very wide usage of things like OpenID Connect Discovery.  PIKA seeks to
address some operational deficiencies in those models, without changing the
trust model.

--Richard

On Wed, Jun 26, 2024 at 8:21 PM Giuseppe De Marco 
wrote:

> Hi Ethan,
>
> I have experience implementing LDAP clients with SASL and SSL, SAML2 SP,
> IDP, MDQ, as well as OpenID Connect RP, OP, and RS. It's clear that X.509
> is foundational to our digital infrastructure, making implementation
> straightforward due to the widespread availability of supporting libraries.
>
> However, X.509 has not addressed all issues; it would be unwise to ignore
> its limitations and pretend it fits all needs perfectly.
>
> I can be an advocate for PIKA and am eager to delve deeper into the
> technical trust requirements envisioned by the PIKA working group
> participants. A new specification should aim to tackle the unresolved
> issues.
>
> Consider this real-world example to illustrate a point: Space Attack
> Spoofing eIDs [1]. The article highlights a vulnerability due to the lack
> of mechanisms for validating endpoints, which opens the door to
> Man-in-the-Middle (MITM) attacks through spoofing.
>
> From my perspective, part of the solution lies in the trust framework
> employed. Even with a vulnerability at one point, having trusted endpoints
> could prevent the attack's success. If endpoints were cryptographically
> attested through verifiable metadata certified by a trusted third party, or
> through a trusted distribution method or trusted policy processing, the
> attack would likely fail. The attacker would not be able to redirect data
> to fraudulent endpoints.
>
> Regardless of the technology, data format, or other elements used, these
> may not align with our personal preferences or comfort levels, I am
> interested in discussing the level of technical trust evaluation we aim to
> incorporate into PIKA. Specifically, which problems are we aiming to solve,
> and which are we deliberately excluding from the scope of this new
> specification.
>
> When selecting a technology for implementation, it is essential to assess
> whether it addresses real-world challenges effectively. I am here to
> investigate if PIKA meets these criteria currently or in the foreseeable
> future, and to understand the roadmap for its development, if available.
> This evaluation is vital for trusting a specification.
>
> I was too verbose, I am sorry.
> Giuseppe
>
> [1]
> https://ctrlalt.medium.com/space-attack-spoofing-eids-password-authenticated-connection-establishment-11561e5657b1
>
> Il giorno mer 26 giu 2024 alle ore 19:08 Ethan Heilman 
> ha scritto:
>
>> I strongly support this draft and would have immediate uses for PIKA
>> if standardized.
>>
>> As someone who builds OIDC relying party software I am not worried
>> about the X.509 certificate requirement, nor do I consider dependence
>> on X.509s or the Web PKI to be an onerous requirement. I already have
>> to deal with parsing and creating X.509 certificates in my relying
>> party software.
>>
>> Given that JWK Set URI's use the Web PKI to authenticate the JWKs they
>> serve via HTTPS, it only seems natural we would use that very same
>> system, the Web PKI, to authenticate JWKs directly.
>>
>> Thanks,
>> Ethan
>>
>>
>> On Tue, Jun 25, 2024 at 8:46 PM Kristina Yasuda
>>  wrote:
>> >
>> > Sorry to chime in late as well…
>> > I support adoption of this draft. I have read the thread and to me it
>> seems like there is a mechanism being proposed that solved a concrete
>> problem in a simple manner. Some of the discussion can happen after the
>> draft is adopted.
>> > Best,
>> > Kristina
>> >
>> >
>> > On Wed, Jun 26, 2024 at 7:49 AM Joseph Salowey  wrote:
>> >>
>> >> Sorry to chime in late here. I'm in favor of adopting this draft.
>> While I realize that X.509 isn't for everyone, there is an established
>> community of users out there that overlaps with OAUTH users.  I think there
>> are needs to both separate the distribution of the keys from the
>> establishment of trust in those keys and in the auditability of the process
>> of distribution.  I think this draft establishes a deployable mechanism
>> based on existing technology.  X.509 is a good starting point and
>> additional mechanisms can be added as needed.
>> >>
>> >> Cheers,
>> >>
>> >> Joe
>> >>
>> >> On Tue, Jun 25, 2024 at 3:12 PM Watson Ladd 
>> wrote:
>> >>>
>> >>> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
>> >>>  wrote:
>> >>> >
>> >>> > The other critique I voiced of the approach is that the
>> application-level X.509 certificate can be used to secure the HOST part of
>> the issuer, but not the entire issuer, since in general, the issuer will
>> contain a PATH.  Yes, the service hosting the issuers controls all the

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

Hi all,

Replying to the top of the thread again to recap the arguments so far.
(Hoping the chairs will give us a moment more to discuss before calling
cloture.)

It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t.
the X.509-based mechanisms in the current draft.  In particular, we're all
developers of relying party software, and it seems like we're all OK with
doing X.509 (contra Mike's point about application-level X.509).

If I understand Mike and Giuseppe correctly, they want to be less
prescriptive about how the PIKA signer establishes their authority for an
"iss" value, so that an OP could use some other mechanism (e.g., OpenID
Federation).  It sounds like Mike at least is OK with the draft aside from
this point.

I would be open to adding some optionality in the authority mechanism here,
but I'm wary of losing the concrete interop that we get with the draft as
it is.  So we would need at least a strong recommendation for X.509, even
if something else can be used if the parties agree to it.  I would be more
comfortable doing something along the lines of what Rohan suggests, namely
defining a concrete, X.509-based thing here, and extending it to support
other mechanisms via follow-on specs as needed.  If there were a single
additional mechanism that people wanted, as opposed to a generic "[insert
authority mechanism here]", that would also be more palatable to me.

Additional feedback would be useful on a couple of points:

1. From RPs: Is the X.509 requirement onerous to you?  Or is there enough
library support out there that it's not a big deal?
2. From OPs: Is signing using a key bound to an X.509 certificate workable
for you?  Or do you need some other authority framework?
3. From everyone: Is the general mechanism here useful, assuming we can
align on some set of authority frameworks?

Thanks,
--Richard


On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Proof of Issuer Key
> Authority (PIKA)* draft:
> 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 -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

The applications we're talking about are **already** doing X.509 when they
make HTTPS connections.  It's not a new requirement.  The only thing we're
doing is using the certificate for JWT instead of HTTPS.

--RLB

On Mon, Jun 10, 2024 at 11:15 PM Michael Jones 
wrote:

> As both I and Giuseppe pointed out, the requirement for applications to
> use and understand X.509 certificates means that the draft is way beyond
> the minimum complexity needed.
>
>
>
> Eliminate application-level X.509 (which is an anachronism that OAuth and
> JOSE have moved away from), and I’ll support adoption of the next draft.
>
>
>
>         -- Mike
>
>
>
> *From:* Richard Barnes 
> *Sent:* Monday, June 10, 2024 8:11 PM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* [OAUTH-WG] Re: Call for adoption - PIKA
>
>
>
> In case it's not clear from other messages in this thread: I think this
> draft should be adopted.  It solves several pressing use cases, with the
> minimal amount of complexity needed.
>
>
>
> --Richard
>
>
>
> On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> All,
>
> This is an official call for adoption for the *Proof of Issuer Key
> Authority (PIKA)* draft:
>
> 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 -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

In case it's not clear from other messages in this thread: I think this
draft should be adopted.  It solves several pressing use cases, with the
minimal amount of complexity needed.

--Richard

On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Proof of Issuer Key
> Authority (PIKA)* draft:
> 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 -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

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 
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.
> Current

[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes]

Hi Mike,

The intent here is to follow exactly the same security model as current
HTTPS-based OP key discovery mechanisms, e.g., OpenID Connect Discovery.
With those mechanisms:

1. The only way the issuer is authenticated is via a certificate presented
in HTTPS.
2. The only aspect of the URL that is authenticated is the domain name.  In
multi-tenant environments, whoever owns the domain name can speak for any
tenants.

Changing the first property would make this document non-interoperable,
since it is no longer clear how the relying party is supposed to verify the
PIKA signature.  Changing the second property would require inventing some
new PKI-ish thing that can authenticate more of a URL.

Do you have some specific additional mechanism that you think needs to be
accommodated here?  If not, I would propose we follow the YAGNI principle,
be specific, and if we need to extend later, we can do a follow-on spec.
Otherwise it's just abstraction for abstraction's sake.

Cheers,
--Richard

On Mon, Jun 10, 2024 at 12:14 PM Michael Jones 
wrote:

> While I’m generally supportive of the goals of this draft, I have issues
> with the mechanisms proposed.  Therefore, I believe that more working group
> discussion is needed before adoption.
>
>
>
> If I were to do something along these lines, I would not use “x5c”.  Other
> than for TLS certificates, the OAuth and JOSE specs generally steer clear
> of dependence upon X.509 certificates.  Especially for a spec focused on
> JWK Sets, it’s odd to require an X.509 certificate to secure them.
> Instead, I’d do so by validating the signature made by the issuer.
>
>
>
> Also, the spec says:
>
>*  The JOSE Header of the PIKA MUST contain an x5c field.  The
>
>   contents of this field MUST represent a certificate chain that
>
>   authenticates the domain name in the iss field.  The domain name
>
>   MUST appear as a dNSName entry in the subjectAltName extension of
>
>   the end-entity certificate.
>
>
>
> This talks about the domain name of the issuer, but not the path within
> the issuer.  In multi-tenant systems, issuers typically include path
> components.  When the issuer is https://example.com/tenant/123, what
> would the DNSName entry be?  The spec doesn’t say.
>
>
>
> Conclusion: Not ready for adoption
>
>
>
> -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef 
> *Sent:* Monday, June 10, 2024 4:47 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Call for adoption - PIKA
>
>
>
> All,
>
> This is an official call for adoption for the *Proof of Issuer Key
> Authority (PIKA)* draft:
>
> 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 -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] Signed JWK Sets

[Richard Barnes]

Hi all,

Thanks for all the feedback on-list and at IETF 119.  Sharon and I took a
second pass at this idea and actually made an Internet-Draft this time:

https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/

The new draft is focused on "Proofs of Issuer Key Authority".  This new
framing is based on a couple of important bits of feedback from Mike Jones,
(1) that OpenID Federation had already defined most of what we need, and
(2) that it would help to be clear that the real focus here was on
replacing HTTPS with JWT as the proof that a key is authoritative for a
given issuer.  Given that, we reuse the "historical JWK set" format from
OpenID Federation, and of course, focus on the "key authority" issue.

Obviously, more feedback is welcome, but especially on whether this would
be a good thing for the OAuth WG to work on.

Thanks,
--Richard


On Sun, Mar 17, 2024 at 1:55 AM Richard Barnes  wrote:

> Hi all,
>
> A few of us have been considering use cases for JWTs related to Verifiable
> Credentials and container signing, which require better "proof of
> authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick
> specification for how to sign a JWK set, and how you might extend discovery
> mechanisms to present such a signed JWK set:
>
>
> https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md
>
> (Just in GitHub for now; will publish as an I-D when the window reopens
> tomorrow.)
>
> If we could get this functionality added to OAuth / OIDC, it would make
> these use cases work a lot better.  As a prelude toward proposing working
> group adoption, it would be great to know if this design seems helpful to
> other folks as well.  Obviously, happy to answer any questions / comments.
>
> Thanks,
> --Richard
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Richard Barnes]

Hi Mike,

Thanks for these links.  These do indeed cover a bunch of piece parts, but
they're still missing a key point for the use cases, namely: A mechanism
for a Relying Party to verify that a signer is authoritative for a given
issuer ID.

The OpenID Federation spec assumes that relying parties are configured with
a Trust Anchor that represents the federation.  (It effectively makes a PKI
encoded in JWTs.)  OpenID Connect and SD-JWT-VC rely on a domain name PKI
(e.g., the Web PKI) instead of a special federation hierarchy.  In other
words, the "x5c" field in this document is the moral equivalent of the
"trust chain" header parameter in OpenID Federation [1].

So there is still a gap here from the perspective of the use cases
described in the document.  Given the overlap here, maybe it would be
useful to pull the Signed JWK Set bits out of OpenID Federation into an
OAuth document to facilitate their re-use elsewhere.

Best,
--Richard

[1]
https://openid.net/specs/openid-federation-1_0.html#name-trust-chain-header-paramete

On Mon, Mar 18, 2024 at 9:28 AM Michael Jones 
wrote:

> Also, see the additional key parameter registrations
> https://openid.net/specs/openid-federation-1_0.html#section-16.8, which
> can be used to indicate key expiration time, etc.
>
>
>
> *From:* Michael Jones
> *Sent:* Sunday, March 17, 2024 7:00 PM
> *To:* Richard Barnes ; oauth@ietf.org WG 
> *Cc:* Sharon Goldberg 
> *Subject:* RE: [OAUTH-WG] Signed JWK Sets
>
>
>
> Signed JWK Sets are part of the OpenID Federation specification and are in
> production use.  For instance, see
> https://openid.net/specs/openid-federation-1_0.html#name-metadata-extensions-for-jwk
> and the “keys” registration at
> https://openid.net/specs/openid-federation-1_0.html#name-registry-contents-7.
> I believe that should already do what you need.  If you believe it doesn’t,
> I’d be curious to discuss why not with you here in Brisbane.
>
>
>
> Best
> wishes,
>
>         -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Richard Barnes
> *Sent:* Sunday, March 17, 2024 3:55 PM
> *To:* oauth@ietf.org WG 
> *Cc:* Sharon Goldberg 
> *Subject:* [OAUTH-WG] Signed JWK Sets
>
>
>
> Hi all,
>
>
>
> A few of us have been considering use cases for JWTs related to Verifiable
> Credentials and container signing, which require better "proof of
> authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick
> specification for how to sign a JWK set, and how you might extend discovery
> mechanisms to present such a signed JWK set:
>
>
>
>
> https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md
>
>
>
> (Just in GitHub for now; will publish as an I-D when the window reopens
> tomorrow.)
>
>
>
> If we could get this functionality added to OAuth / OIDC, it would make
> these use cases work a lot better.  As a prelude toward proposing working
> group adoption, it would be great to know if this design seems helpful to
> other folks as well.  Obviously, happy to answer any questions / comments.
>
>
>
> Thanks,
>
> --Richard
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Richard Barnes]

Hi Watson,

I appreciate the concerns with regard to re-using Web PKI certs for cases
such as these.  Care is required, but I think there is a path here.

1. Clearly there are cross-protocol concerns.  I expect that most usage
here in reality would be based on ECDSA / EdDSA, not RSA, which helps.  I
would be comfortable with security considerations recommending that a key
pair / certificate used for signing these things be used for no other
purpose.

2. Validity times are definitely a challenge for the container signing use
case, but from the conversations I've had with that community, they are
taking an orthogonal approach.  As I tried to sketch in the document, they
are establishing authorities that will vouch that a signed thing existed at
a given time, so that a relying party can safely rewind their clock and
validate as if it were that time.  See, e.g., SigStore <
https://www.sigstore.dev/>, which has roughly this shape if you squint
right.

3. I don't think there's actually any disconnect between HTTPS
authentication and proof of authority.  The Web PKI is about authenticating
domain names, which is what both use cases require.

Best,
--Richard

On Mon, Mar 18, 2024 at 10:23 AM Watson Ladd  wrote:

> On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes  wrote:
> >
> > Hi all,
> >
> > A few of us have been considering use cases for JWTs related to
> Verifiable Credentials and container signing, which require better "proof
> of authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick
> specification for how to sign a JWK set, and how you might extend discovery
> mechanisms to present such a signed JWK set:
> >
> >
> https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md
> >
> > (Just in GitHub for now; will publish as an I-D when the window reopens
> tomorrow.)
> >
> > If we could get this functionality added to OAuth / OIDC, it would make
> these use cases work a lot better.  As a prelude toward proposing working
> group adoption, it would be great to know if this design seems helpful to
> other folks as well.  Obviously, happy to answer any questions / comments.
>
> I have concerns about this proposal. First we need to ban any use of
> RSA-1.5 encryption (aka TLS 1.2) with the certificates used here. This
> is not really possible in TLS as commonly implemented for reasons, and
> can't be determined from the certificate alone (unless it's RSA-PSS
> certificate with special stuff that hopefully is honored or ECDSA).
> Then there's a philosphical issue to reusing keys for different
> purposes that requires domain separation ala TLS 1.3, and likely some
> X509 extensions as well to really nail it.
>
> Secondly there are a bunch of layer 8 question with the Web PKI this
> raises. The web PKI is moving to short term issuance and possibly
> removal of revocation entirely if certificates can be sufficiently
> short term. For signatures on containers this is inappropriate: a
> verification that a container is the correct container needs to be
> possible long after 90 days or a week, and this means the keying
> material that was used to make that signature must be held secure
> afterwards. This runs straight up into what we're trying to do to
> improve the Web PKI, and using the Web PKI for other things often
> leads to pain.
>
> Thirdly the web PKI issuance methods make sense from a web
> perspective, but not necessarily from a codesigning perspective. What
> we want to validate is different. Organizationally websites and
> codesigning often belong in different places. At the same time there's
> a barrier to alternatives, especially the ones that don't exist (see
> also Roughtime for my personal experience with this). These issues get
> real thorny real fast.
>
> Sincerely,
> Watson Ladd
>
>
> --
> Astra mortemque praestare gradatim
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Signed JWK Sets

[Richard Barnes]

Hi all,

A few of us have been considering use cases for JWTs related to Verifiable
Credentials and container signing, which require better "proof of
authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick
specification for how to sign a JWK set, and how you might extend discovery
mechanisms to present such a signed JWK set:

https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md

(Just in GitHub for now; will publish as an I-D when the window reopens
tomorrow.)

If we could get this functionality added to OAuth / OIDC, it would make
these use cases work a lot better.  As a prelude toward proposing working
group adoption, it would be great to know if this design seems helpful to
other folks as well.  Obviously, happy to answer any questions / comments.

Thanks,
--Richard
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] SD-JWT, implementation and comments

[Richard Barnes]

Hi all,

My favorite way to understand a draft is to implement it, so I did a quick
implementation of SD-JWT while sitting in IETF sessions last week (in Rust,
as an extension to the `jwt` crate, which seems pretty mature and widely
used).  Currently in first-draft form, but in case anyone is interested:

https://github.com/bifurcation/rust-jwt/pull/1

Overall, my assessment is that the document is fundamentally sound but
could use some clarifications and some minor technical improvements.  I
have filed the latter as issues on the GitHub repo:

#375 - Make SD-JWT(0) and JWT the same
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/375

#374 - Separate token and presentation formats
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/374

#373 - Validate that disclosures match the issuer JWT
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/373

#372 - Forbid recursive redaction
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/372

#371 - Remove initial underscore on _sd_hash
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/371

Best,
--Richard
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

Looks good to me, thanks.  I cleared.
--Richard

On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones 
wrote:

>  Richard, yours are the only discusses on draft-ietf-oauth-assertions,
> draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re
> all about the audience requirement. Brian added text addressing this in
> the last paragraph of
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.
> Are you willing to clear these DISCUSSes on this basis?
>
>
>
> If not, can we try to talk before the OAuth meeting tomorrow morning?
> I’ll be leading the assertions drafts discussions tomorrow since Brian
> won’t be able to attend.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Friday, October 17, 2014 8:23 AM
> *To:* Richard Barnes
> *Cc:* John Bradley; draft-ietf-oauth-asserti...@tools.ietf.org; Pete
> Resnick; oauth; The IESG; oauth-cha...@tools.ietf.org
> *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
>
>
>
> That text works for me, Richard. Thanks.
>
> I will go with Richard's text in the next draft, unless I hear objections.
>
>
>
> FWIW, the mention of HoK was a result of a review and suggestions from
> Hannes some time ago.
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt
>
>
>
> It could be removed, to your point, but I think your proposed text is very
> clear about the scope and might help prevent confusion.
>
>
>
>
>
> On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes  wrote:
>
> On Fri, Oct 17, 2014 at 10:32 AM, John Bradley  wrote:
>
>  I think this part of sec 3 of assertions states that:
>
>
>
>  The protocol parameters and processing rules defined in this document
>
>are intended to support a client presenting a bearer assertion to an
>
>authorization server.  The use of holder-of-key assertions are not
>
>precluded by this document, but additional protocol details would
>
>need to be specified.
>
>
>
>
>
> As part of defining the additional protocol details for holder-of-key/PoP
> we can relax the must for audience in the profile that defines how to use
> those assertion types.
>
>
>
> I think we're on a path to convergence here.
>
>
>
> Given all this, is there any point to even mentioning HoK credentials
> here?  The entire remainder of the spec is written as if they didn't
> exist.  And as the text above notes, you can't actually use them with this
> specification.
>
> If we're going to keep the mention, could we augment the text above to
> make it clearer that HoK assertions are out of scope.
>
>
> """
>
> The protocol parameters and processing rules defined in this document
> are intended to support a client presenting a bearer assertion to an
> authorization server.  They are not suitable for use with holder-of-key
> assertions.  While they could be used as a baseline for a holder-of-key
>
> assertion system, there would be a need for additional mechanisms
>
> (to support proof of possession of the secret key), and possibly changes
> to the security model (e.g., to relax the requirement for an Audience).
>
> """
>
> --Richard
>
>
>
>
>
>
> John B.
>
>
>
> On Oct 17, 2014, at 2:25 PM, Pete Resnick 
> wrote:
>
>
>
>  On 10/17/14 12:09 PM, Mike Jones wrote:
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
> Do you mean you shouldn't consider making it optional for HoK? Again,
> making it clear that the MUST applies only to bearer assertions, and that
> future extensions for HoK might have different requirements, is all that is
> being asked for here.
>
> pr
>
>  --
>
> Pete Resnick <http://www.qualcomm.com/~presnick/> 
> <http://www.qualcomm.com/~presnick/>
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

[Richard Barnes]

Dude, I cleared on the 10th :)

On Tue, Oct 14, 2014 at 5:53 AM, Mike Jones 
wrote:

> The proposed resolution below has been incorporated in the -28 draft.
> Hopefully you can clear your DISCUSS on that basis.
>
> Thanks again,
> -- Mike
>
> > -Original Message-
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> > Sent: Saturday, October 11, 2014 12:54 PM
> > To: Richard Barnes
> > Cc: draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth-
> > cha...@tools.ietf.org; The IESG; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-json-web-
> > token-27: (with DISCUSS and COMMENT)
> >
> > > From: Richard Barnes [mailto:r...@ipv.sx]
> > > Sent: Friday, October 10, 2014 2:37 PM
> > > To: Mike Jones
> > > Cc: The IESG; oauth-cha...@tools.ietf.org; oauth@ietf.org;
> > > draft-ietf-oauth-json-web-to...@tools.ietf.org
> > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
> > > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
> > >
> > > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones
> >  wrote:
> > > Thanks for your review, Richard.  My responses are inline below...
> > >
> > > > -Original Message-
> > > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard
> > > > Barnes
> > > > Sent: Wednesday, October 01, 2014 7:57 PM
> > > > To: The IESG
> > > > Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org;
> > > > draft-ietf-oauth-json-web- to...@tools.ietf.org
> > > > Subject: [OAUTH-WG] Richard Barnes' Discuss on
> > > > draft-ietf-oauth-json-web-
> > > > token-27: (with DISCUSS and COMMENT)
> > > >
> > > > Richard Barnes has entered the following ballot position for
> > > > draft-ietf-oauth-json-web-token-27: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to
> > > > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
> > > >
> > > >
> > > >
> > > > 
> > > > --
> > > > DISCUSS:
> > > > 
> > > > --
> > > >
> > > > Section 7.
> > > > In order to prevent confusion between secured and Unsecured JWTs,
> > > > the validation steps here need to call for the application to
> specify which is
> > required.
> > >
> > > Per my response on your JWS comments, this is already handed in a more
> > general way in the JWS validation steps.  Specifically, the last
> paragraph of
> > Section 5.2 is:
> > >
> > > "Finally, note that it is an application decision which algorithms are
> acceptable
> > in a given context. Even if a JWS can be successfully validated, unless
> the
> > algorithm(s) used in the JWS are acceptable to the application, it
> SHOULD reject
> > the JWS."
> > >
> > > I've cleared this DISCUSS in the interest of having this fight over in
> JWS thread.
> > But I also added the following COMMENT:
> > > "It would be good for this document to pass on the note from JWS about
> > selecting which algorithms are acceptable, and in particular, whether
> unsecured
> > JWTs are acceptable."
> >
> > Thanks for clearing the DISCUSS.  I'm fine repeating the note about
> acceptable
> > algorithms in the JWT spec, assuming others are.
> >
> > > I would therefore request that you likewise withdraw this DISCUSS on
> that
> > basis.
> >
> >   -- Mike
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

[Richard Barnes]

On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell 
wrote:

>
>
> On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes  wrote:
>
>>
>>
>> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Thanks for your review and feedback on this one too, Richard. Replies
>>> are inline below...
>>>
>>> On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes  wrote:
>>>
>>>> Richard Barnes has entered the following ballot position for
>>>> draft-ietf-oauth-jwt-bearer-10: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/
>>>>
>>>>
>>>>
>>>> --
>>>> DISCUSS:
>>>> --
>>>>
>>>> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim
>>>> seems entirely unnecessary.  Holding this DISCUSS point pending that
>>>> discussion
>>>> and its reflection in this document.
>>>>
>>>> "Assertions that do not identify the Authorization Server as an intended
>>>> audience MUST be rejected." -- What does it mean for an assertion to
>>>> "identify
>>>> the Authorization Server"?  Does the specified  need to match
>>>> the
>>>> entire URL of the relevant OAuth endpoint?  Just the origin?  Just the
>>>> domain?
>>>> Does the URL need to be canonicalized?
>>>>
>>>>
>>>
>>> No c14n, as it says, "...  compare the audience values using the Simple
>>> String Comparison method defined in Section 6.2.1 of RFC 3986."
>>>
>>> Basically the AS is at liberty to determine how it identifies itself.
>>> Some guidance on using the token endpoint is provided but it's ultimately
>>> up to the AS (or the larger deployment in which the AS exists). The
>>> acceptable value is one of a few bits of information that must be exchanged
>>> for this profile, which is discussed in the Interoperability Considerations
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5
>>>
>>
>> Sigh.  "Negotiate it out of band" is a terrible, non-scalable,
>> not-in-the-spirit-of-the-Internet answer.  But I guess I might clear on
>> this if you could add something like the following:
>> "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise
>> strings to be used as the Audience for a given Authorization Server must be
>> configured out-of-band by the Authorization Server and the Issuer of the
>> assertion."
>>
>
>
>
> I'll add the suggested text.
>

Great.  Let me know when the revised text is posted.

--Richard



>
>
>
>>
>> But is there seriously no answer that the WG could agree on?  This seems
>> like it should be a pretty simple question.  Was it even discussed?
>>
>>
>
>
> It was discussed but it's not simple for reasons I've tried to articulate
> many times.
>
> Note that the specific profiling or usage of these specs can constrain or
> dictate the values of this and other the things that needing out of band
> negotiation and can be more in the spirit of the Internet to the extent
> that they define dynamic exchange/discovery/registration/etc. of required
> information. But these little documents need to fit into such larger
> contexts not try and define them.
>
>
>
>> --Richard
>>
>>
>>
>>> Some more explanation/discussion of it is in the middle(ish) of this
>>> reply to a similar comment from Stephen Farrell
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html
>>>
>>>
>>>
>>>> --
>>>> COMMENT:
>>>> --
>>>>
>>>> "keyed message digest" -> "MAC"
>>>>
>>>
>>> Yep.
>>>
>>>
>>>>
>>>> Both this and the SAML document could save a lot of bits by just being
>>>> subsections of the -assertions document.
>>>>
>>>
>>> The structure and relationship of the documents was decided on by the WG
>>> nearly three years ago. There is some duplication but it's believed to be
>>> more approachable this way - particularly for those implementing just one
>>> assertion type.
>>>
>>
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

It's a known set of actual attacks ... on bearer assertions.  There is no
corresponding attack on HoK assertions.

We shouldn't consider making it optional for bearer assertions.  For HoK,
there's no reason for it not to be optional.

On Fri, Oct 17, 2014 at 10:09 AM, Mike Jones 
wrote:

>  +1
>
>
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Phil Hunt
> *Sent:* Friday, October 17, 2014 9:50 AM
> *To:* John Bradley
> *Cc:* draft-ietf-oauth-asserti...@tools.ietf.org; Richard Barnes;
> oauth-cha...@tools.ietf.org; The IESG; oauth
> *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
>
>
>
> I believe that if you make “aud” optional, it only helps the simplistic
> deployment scenarios where there is only one RS and one AS. The optionality
> itself will cause more confusion.  In the simplistic case, the AS and RS
> simply have to agree on a URI.
>
>
>
> In more sophisticated domains where there is more than one RS service, the
> “aud” value is expected and is useful to determining who a token is
> intended for.
>
>
>
> Finally, there is the 3rd level case where the AS and the RS are in
> separate domains (federated). In this case, we can expect inter-op to be
> required between separate vendors as a majority of cases.
>
>
>
> Making “aud” optional will greatly increase complexity in reality.  Making
> it a MUST only puts a trivial imposition on the trivial case (they have to
> provide a made up URI).
>
>
>
> We did not really discuss “aud" much on the list because it is well known
> industry practice. I would not want to suggest re-writing something that
> works well.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com
>
> phil.h...@oracle.com
>
>
>
>
>
>
>
> On Oct 17, 2014, at 9:01 AM, John Bradley  wrote:
>
>
>
>  I am good with it as is.  I think we have the flexibility to add HoK
> later.
>
>
>
> I mostly wanted to point out that it is really only in that later HoK
> profile where omitting audience is safe.
>
>
>
> If I had the power to remove the DISCUS I would.
>
>
>
> John B.
>
>
>
> On Oct 17, 2014, at 12:56 PM, Brian Campbell 
> wrote:
>
>
>
>   These drafts define the use of bearer assertions. The only mention of
> HoK style assertions is at the end of
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3
> which notes that the "rules defined in this document are intended to
> support a client presenting a bearer assertion to an authorization server.
> The use of holder-of-key assertions are not precluded by this document, but
> additional protocol details would need to be specified."
>
> The requirement of having audience is for bearer assertions only (and we
> agree need to be that way for bearer) and not intended to preclude anything
> for HoK assertions.
>
> Does that change your opinion? Is there something that could be added or
> removed or clarified to allay concerns?
>
>
>
>
>
> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
>
> Holder of key JWT is still in draft and we don't have a clear way to
> present the proof to the token endpoint.
>
>
>
> Brian and I started discussing that last week as I happen to have a use
> case for a PoP JWT assertion flow in some other spec work.
>
>
>
> I think that there is enough difference between bearer and PoP that doing
> a follow on profile for SAML and JWT that can also cover the proof
> presentment mechanisms makes the most sense.
>
>
>
> I would go with restricting this to Bearer and MUST for audience,  and
> removing the audience requirement explicitly in the PoP profiles.
>
>
>
> There are people who need the bearer version 6 months ago,  I don't want
> to do anything to hold it up based on future work.
>
>
>
> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML
> subject confirmation stuff is relatively clear so it is mostly defining the
> presentment mechanisms like mutual TLS and a self signed assertion. (we
> need to be careful not to conflate client authentication and token proof,
> as they are different and might both be used at the same time.
>
>
>
> John B.
>
>
>
> On Oct 16, 2014, at 7:20 PM, Richard Barnes  wrote:
>
>
>
>   You guys are all arguing that having an Audience ca

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

On Fri, Oct 17, 2014 at 10:32 AM, John Bradley  wrote:

> I think this part of sec 3 of assertions states that:
>
>  The protocol parameters and processing rules defined in this document
>are intended to support a client presenting a bearer assertion to an
>authorization server.  The use of holder-of-key assertions are not
>precluded by this document, but additional protocol details would
>need to be specified.
>
>
>
> As part of defining the additional protocol details for holder-of-key/PoP
> we can relax the must for audience in the profile that defines how to use
> those assertion types.
>

I think we're on a path to convergence here.

Given all this, is there any point to even mentioning HoK credentials
here?  The entire remainder of the spec is written as if they didn't
exist.  And as the text above notes, you can't actually use them with this
specification.

If we're going to keep the mention, could we augment the text above to make
it clearer that HoK assertions are out of scope.

"""
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server.  They are not suitable for use with holder-of-key
assertions.  While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly changes
to the security model (e.g., to relax the requirement for an Audience).
"""

--Richard




>
> John B.
>
> On Oct 17, 2014, at 2:25 PM, Pete Resnick 
> wrote:
>
>  On 10/17/14 12:09 PM, Mike Jones wrote:
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
> Do you mean you shouldn't consider making it optional for HoK? Again,
> making it clear that the MUST applies only to bearer assertions, and that
> future extensions for HoK might have different requirements, is all that is
> being asked for here.
>
> pr
>
> --
> Pete Resnick  
> 
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

On Thu, Oct 16, 2014 at 3:20 PM, Richard Barnes  wrote:

> You guys are all arguing that having an Audience can be useful.  I don't
> disagree.  I disagree that it should be REQUIRED in all cases.
>
> The Google vulnerability that Brian raised was an interesting read, but as
> John points out, it only applies to Bearer Assertions.  There's no security
> requirement at all for holder-of-key assertions to have an audience, since
> they can't be replayed by someone who doesn't hold the key.
>
> I could agree that an audience should be REQUIRED for bearer assertions.
> Since they are vulnerable to replay, Audience protects against the
> Authorization Server re-using the token.  (It would be good to say this
> explicitly in the doc, actually.)  But for holder-of-key assertions, the
> Audience should be OPTIONAL.  Note that this requires that instance
> documents define the difference between bearer assertions and holder-of-key
> assertions, so that implementations can enforce these requirements.
>
> So it seems like there are two solutions here:
> 1. Scope the document to bearer assertions only, and keep the MUST
> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key
> assertions, and define the difference in the instance docs.
>

I'll also offer a third resolution:
3. Show me that the WG discussed this question and made the decision to
forbid holder-of-key assertions without an Audience parameter.

--Richard




> --Richard
>
>
>
>
>
>
> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>
>> It is also important for a non-protocol purpose. Liability.
>>
>> If a 3rd party uses an assertion that was not intended for it, it cannot
>> obviously hold the asserting party responsible.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>>
>>
>>
>> On Oct 16, 2014, at 8:43 AM, Brian Campbell 
>> wrote:
>>
>> Thanks for your review and feedback, Richard. Replies are inline below...
>>
>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>>
>>> Richard Barnes has entered the following ballot position for
>>> draft-ietf-oauth-assertions-17: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> "The assertion MUST contain an Audience that identifies the Authorization
>>> Server as the intended audience.  Assertions that do not identify the
>>> Authorization Server as an intended audience MUST be rejected."
>>>
>>> Could you please identify the threat model within which this "MUST" is
>>> required?  This requirement doesn't follow from any of the threats
>>> elaborated in Section 8.
>>>
>>> The Audience is only necessary if the Issuer wishes to constrain the set
>>> of Authorization Servers with which an assertion may be used.  So ISTM
>>> that this should be "MAY contain..."
>>>
>>>
>>
>> The audience restriction let's the issuer say specifically what relying
>> party is allowed to consume the assertion, which ensures that the client
>> can't use it somewhere else that it wasn't intended and that the relying
>> party that receives the assertion can't turn around and use it to access
>> some other service.
>>
>> Strictly speaking, you are right that the audience is only necessary if
>> the Issuer wishes to constrain the set of Authorization Servers with which
>> an assertion may be used. But the Issuer really really really should make
>> that constraint and fully understanding the implications of not doing so is
>> difficult and unlikely.
>>
>> There was a vulnerability in Google apps SAML a few years back that
>> demonstrates how important audience restriction is and how it can be
>> difficult for even very sophisticated providers to get it all right. I
>> haven&#x

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS)

[Richard Barnes]

That's what you get for duplicating all the text :)

On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell 
wrote:

> Basically the same response to the basically same question as from
> http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html
>
> On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes  wrote:
>
>> Richard Barnes has entered the following ballot position for
>> draft-ietf-oauth-saml2-bearer-21: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> As with draft-ietf-oauth-assertions, the requirement for an 
>> element seems entirely unnecessary.  Holding this DISCUSS point pending
>> that discussion and its reflection in this document.
>>
>> "Assertions that do not identify the Authorization Server as an intended
>> audience MUST be rejected." -- What does it mean for an assertion to
>> "identify the Authorization Server"?  Does the specified  need
>> to match the entire URL of the relevant OAuth endpoint?  Just the origin?
>>  Just the domain?  Does the URL need to be canonicalized?
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

[Richard Barnes]

On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell 
wrote:

> Thanks for your review and feedback on this one too, Richard. Replies are
> inline below...
>
> On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes  wrote:
>
>> Richard Barnes has entered the following ballot position for
>> draft-ietf-oauth-jwt-bearer-10: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim
>> seems entirely unnecessary.  Holding this DISCUSS point pending that
>> discussion
>> and its reflection in this document.
>>
>> "Assertions that do not identify the Authorization Server as an intended
>> audience MUST be rejected." -- What does it mean for an assertion to
>> "identify
>> the Authorization Server"?  Does the specified  need to match
>> the
>> entire URL of the relevant OAuth endpoint?  Just the origin?  Just the
>> domain?
>> Does the URL need to be canonicalized?
>>
>>
>
> No c14n, as it says, "...  compare the audience values using the Simple
> String Comparison method defined in Section 6.2.1 of RFC 3986."
>
> Basically the AS is at liberty to determine how it identifies itself. Some
> guidance on using the token endpoint is provided but it's ultimately up to
> the AS (or the larger deployment in which the AS exists). The acceptable
> value is one of a few bits of information that must be exchanged for this
> profile, which is discussed in the Interoperability Considerations
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5
>

Sigh.  "Negotiate it out of band" is a terrible, non-scalable,
not-in-the-spirit-of-the-Internet answer.  But I guess I might clear on
this if you could add something like the following:
"As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise strings
to be used as the Audience for a given Authorization Server must be
configured out-of-band by the Authorization Server and the Issuer of the
assertion."

But is there seriously no answer that the WG could agree on?  This seems
like it should be a pretty simple question.  Was it even discussed?

--Richard



> Some more explanation/discussion of it is in the middle(ish) of this reply
> to a similar comment from Stephen Farrell
> http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html
>
>
>
>> --
>> COMMENT:
>> --
>>
>> "keyed message digest" -> "MAC"
>>
>
> Yep.
>
>
>>
>> Both this and the SAML document could save a lot of bits by just being
>> subsections of the -assertions document.
>>
>
> The structure and relationship of the documents was decided on by the WG
> nearly three years ago. There is some duplication but it's believed to be
> more approachable this way - particularly for those implementing just one
> assertion type.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

You guys are all arguing that having an Audience can be useful.  I don't
disagree.  I disagree that it should be REQUIRED in all cases.

The Google vulnerability that Brian raised was an interesting read, but as
John points out, it only applies to Bearer Assertions.  There's no security
requirement at all for holder-of-key assertions to have an audience, since
they can't be replayed by someone who doesn't hold the key.

I could agree that an audience should be REQUIRED for bearer assertions.
Since they are vulnerable to replay, Audience protects against the
Authorization Server re-using the token.  (It would be good to say this
explicitly in the doc, actually.)  But for holder-of-key assertions, the
Audience should be OPTIONAL.  Note that this requires that instance
documents define the difference between bearer assertions and holder-of-key
assertions, so that implementations can enforce these requirements.

So it seems like there are two solutions here:
1. Scope the document to bearer assertions only, and keep the MUST
2. Keep the current scope, make Audience OPTIONAL for holder-of-key
assertions, and define the difference in the instance docs.

--Richard






On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:

> It is also important for a non-protocol purpose. Liability.
>
> If a 3rd party uses an assertion that was not intended for it, it cannot
> obviously hold the asserting party responsible.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Oct 16, 2014, at 8:43 AM, Brian Campbell 
> wrote:
>
> Thanks for your review and feedback, Richard. Replies are inline below...
>
> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>
>> Richard Barnes has entered the following ballot position for
>> draft-ietf-oauth-assertions-17: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> "The assertion MUST contain an Audience that identifies the Authorization
>> Server as the intended audience.  Assertions that do not identify the
>> Authorization Server as an intended audience MUST be rejected."
>>
>> Could you please identify the threat model within which this "MUST" is
>> required?  This requirement doesn't follow from any of the threats
>> elaborated in Section 8.
>>
>> The Audience is only necessary if the Issuer wishes to constrain the set
>> of Authorization Servers with which an assertion may be used.  So ISTM
>> that this should be "MAY contain..."
>>
>>
>
> The audience restriction let's the issuer say specifically what relying
> party is allowed to consume the assertion, which ensures that the client
> can't use it somewhere else that it wasn't intended and that the relying
> party that receives the assertion can't turn around and use it to access
> some other service.
>
> Strictly speaking, you are right that the audience is only necessary if
> the Issuer wishes to constrain the set of Authorization Servers with which
> an assertion may be used. But the Issuer really really really should make
> that constraint and fully understanding the implications of not doing so is
> difficult and unlikely.
>
> There was a vulnerability in Google apps SAML a few years back that
> demonstrates how important audience restriction is and how it can be
> difficult for even very sophisticated providers to get it all right. I
> haven't had time to read it again to make sure but I think that this is the
> paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
>
> I don't see what value allowing audience to be omitted brings other than
> that it is academically a possibility. But requiring it (hopefully, if the
> requirement is followed) helps reduce the possibility of a whole bunch of
> security problems that folks likely won't foresee.
>
>
>
>> --
>> COMMENT:
>> --
>>
>> 

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones 
wrote:

> Thanks for your review, Richard.  I'm replying to your DISCUSS about the
> audience being required below...
>
> -- Mike
>
> > -Original Message-
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 15, 2014 8:48 PM
> > To: The IESG
> > Cc: draft-ietf-oauth-asserti...@tools.ietf.org;
> oauth-cha...@tools.ietf.org;
> > oauth@ietf.org
> > Subject: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17:
> > (with DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-oauth-assertions-17: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > "The assertion MUST contain an Audience that identifies the Authorization
> > Server as the intended audience.  Assertions that do not identify the
> > Authorization Server as an intended audience MUST be rejected."
> >
> > Could you please identify the threat model within which this "MUST" is
> required?
> > This requirement doesn't follow from any of the threats elaborated in
> Section 8.
>
> Sure, this is to prevent a legitimate assertion intended for one
> authorization server being captured by the attacker and sent to a different
> authorization server.  Unless there's an audience for the authorization
> server to check, there's no way for the authorization server to reject
> assertions intended to be used by a different server.  Using the audience
> is the normal way to prevent this attack.
>

That all assumes that the issuer of the assertion intends to limit it to a
specific authorization server.  That is not the case with many assertion
systems today, e.g., PKIX.



> > The Audience is only necessary if the Issuer wishes to constrain the set
> of
> > Authorization Servers with which an assertion may be used.  So ISTM that
> this
> > should be "MAY contain..."
>
> Constraining the set to the intended server is basic to the security
> guarantees.  If I can take a server intended for server1 and get server2 to
> accept it, all security bets are off.
>

That's dramatically overstating things.  The only security bet that is off
in that case is that the assertion is not limited to one authorization
server.  Which may or may not be the issuer's intent.

The only thing I could see justifying this requirement is something in the
overall OAuth architecture that requires authorizations to be scoped to a
specific authorization server.  If that exists, add a citation and I'll
clear.  Otherwise, this needs to be un-MUST-ed.

--Richard




>
> > --
> > COMMENT:
> > --
> >
> > "keyed message digest" -> "Message Authentication Code"
> >
> > That's the proper terminology [RFC4949], especially since there are MACs
> that
> > are not based on digests.
> >
> > "This mechanism provides additional security properties." -- Please
> delete this or
> > elaborate on what security properties it provides.
> >
> > Section 8.2 should note that "Holder-of-Key Assertions" are also a
> mitigation for
> > this risk.
> >
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

[Richard Barnes]

Richard Barnes has entered the following ballot position for
draft-ietf-oauth-jwt-bearer-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/



--
DISCUSS:
--

As with draft-ietf-oauth-assertions, the requirement for an "aud" claim
seems entirely unnecessary.  Holding this DISCUSS point pending that
discussion
and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intended
audience MUST be rejected." -- What does it mean for an assertion to
"identify
the Authorization Server"?  Does the specified  need to match
the
entire URL of the relevant OAuth endpoint?  Just the origin?  Just the
domain? 
Does the URL need to be canonicalized?


--
COMMENT:
--

"keyed message digest" -> "MAC"

Both this and the SAML document could save a lot of bits by just being
subsections of the -assertions document.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS)

[Richard Barnes]

Richard Barnes has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/



--
DISCUSS:
--

As with draft-ietf-oauth-assertions, the requirement for an 
element seems entirely unnecessary.  Holding this DISCUSS point pending
that discussion and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intended
audience MUST be rejected." -- What does it mean for an assertion to
"identify the Authorization Server"?  Does the specified  need
to match the entire URL of the relevant OAuth endpoint?  Just the origin?
 Just the domain?  Does the URL need to be canonicalized?




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

Richard Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/



--
DISCUSS:
--

"The assertion MUST contain an Audience that identifies the Authorization
Server as the intended audience.  Assertions that do not identify the
Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST" is
required?  This requirement doesn't follow from any of the threats
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set
of Authorization Servers with which an assertion may be used.  So ISTM
that this should be "MAY contain..."


--
COMMENT:
--

"keyed message digest" -> "Message Authentication Code"

That's the proper terminology [RFC4949], especially since there are MACs
that are not based on digests.

"This mechanism provides additional security properties." -- Please
delete this or elaborate on what security properties it provides.

Section 8.2 should note that "Holder-of-Key Assertions" are also a
mitigation for this risk.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

[Richard Barnes]

On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones 
wrote:

> Thanks for your review, Richard.  My responses are inline below...
>
> > -Original Message-
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 01, 2014 7:57 PM
> > To: The IESG
> > Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org;
> draft-ietf-oauth-json-web-
> > to...@tools.ietf.org
> > Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-
> > token-27: (with DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-oauth-json-web-token-27: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Section 7.
> > In order to prevent confusion between secured and Unsecured JWTs, the
> > validation steps here need to call for the application to specify which
> is required.
>
> Per my response on your JWS comments, this is already handed in a more
> general way in the JWS validation steps.  Specifically, the last paragraph
> of Section 5.2 is:
>
> "Finally, note that it is an application decision which algorithms are
> acceptable in a given context. Even if a JWS can be successfully validated,
> unless the algorithm(s) used in the JWS are acceptable to the application,
> it SHOULD reject the JWS."
>

I've cleared this DISCUSS in the interest of having this fight over in JWS
thread.  But I also added the following COMMENT:
"It would be good for this document to pass on the note from JWS about
selecting which algorithms are acceptable, and in particular, whether
unsecured JWTs are acceptable."

--Richard



> I would therefore request that you likewise withdraw this DISCUSS on that
> basis.
> > --
> > COMMENT:
> > --
> >
> > Abstract.
> > Welsh is the only language I know of in which "w" is a vowel.  According
> to
> > Wikipedia, then, "JWT" should pronounced "joot" :)
>
> You're not the only person with knowledge of Welsh to have made this
> comment.  And this is a Jones responding to you... ;-)
>
> > Section 2.
> > It seems like "Unsecured JWT" should simply be defined as "A JWT carried
> in an
> > Unsigned JWS."
>
> It's been useful in other specifications that are applications of JWTs to
> have a name for this kind of JWT, since it occurs frequently.
>
> > Section 4.1.
> > I'm a little surprised not to see a "jwk" claim, which would basically
> enable JWTs
> > to sub in for certificates for many use cases.  Did the WG consider this
> > possibility?
>
> Not to my knowledge.  However, I know of several applications in which
> JWKs and JWK Sets are carried as claims in JWTs of various kinds - just
> using claim names that are informed by the context of the particular
> application.  For instance, draft-ietf-oauth-dyn-reg uses a "jwks_uri"
> claim to pass a JWK Set by reference and a "jwks" claim to pass a JWK Set
> by value.
>
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> Thanks again,
> -- Mike
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

[Richard Barnes]

Richard Barnes has entered the following ballot position for
draft-ietf-oauth-json-web-token-27: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/



--
DISCUSS:
--

Section 7.
In order to prevent confusion between secured and Unsecured JWTs, the
validation steps here need to call for the application to specify which
is required.


--
COMMENT:
--

Abstract.
Welsh is the only language I know of in which "w" is a vowel.  According
to Wikipedia, then, "JWT" should pronounced "joot" :)

Section 2.
It seems like "Unsecured JWT" should simply be defined as "A JWT carried
in an Unsigned JWS."

Section 4.1.
I'm a little surprised not to see a "jwk" claim, which would basically
enable JWTs to sub in for certificates for many use cases.  Did the WG
consider this possibility?


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [jose] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

[Richard Barnes]

I will re-iterate here my strong preference that an "unsecured" or
"plaintext" JWS object be syntactically distinct from a real JWS object.
E.g. by having two dot-separated components instead of three.

Beyond that, seems like just shuffling deck chairs.

On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell 
wrote:

> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.
>
> I agree that "plaintext” is not the most intuitive wording choice and that
> "unsecured" might better convey what's going on with the "none" JWS
> algorithm.
>
> Mike mentioned that, if this change is made in JWT, there are parallel
> changes in JWS. But note that there are also such changes in JWA (more than
> in JWS actually).
>
> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones 
> wrote:
>
>>  -Original Message-
>> From: Warren Kumari [mailto:war...@kumari.net]
>> Sent: Monday, September 01, 2014 3:40 PM
>> To: sec...@ietf.org; draft-ietf-oauth-json-web-token@tools.ietf.org
>> Subject: Review of: draft-ietf-oauth-json-web-token
>>
>> I'm a little confused by something in the Terminology section (Section 2):
>>
>> Plaintext JWT
>>
>> A JWT whose Claims are not integrity protected or encrypted.
>>
>> The term plaintext to me means something like "is readable without
>> decrypting / much decoding" (something like, if you cat the file to a
>> terminal, you will see the information). Integrity protecting a string
>> doesn't make it not easily readable. If this document / JOSE uses
>> "plaintext" differently (and a quick skim didn't find anything about
>>
>> this) it might be good to clarify. Section 6 *does* discuss plaintext
>> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term
>> "plaintext" here.
>>
>>
>>
>> I’ve discussed this with the other document editors and we agree with you
>> that “plaintext” is not the most intuitive wording choice in this context.
>> Possible alternative terms are “Unsecured JWT” or “Unsigned JWT”.  I think
>> that “Unsecured JWT” is probably the preferred term, since JWTs that are
>> JWEs are also unsigned, but they are secured.  Working group – are you OK
>> with this possible terminology change?  (Note that the parallel change
>> “Plaintext JWS” -> “Unsecured JWS” would also be made in the JWS spec.)
>>
>>
>>
>
> ___
> jose mailing list
> j...@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Plaintext JWT bug

[Richard Barnes]

This thread is about the proposed change to JWT.  Further discussion of the
risks of "alg":"none" will be on the JOSE list.

--Richard




On Thu, Aug 1, 2013 at 2:26 PM, Mike Jones wrote:

>  You prevent downgrade attacks by having your application reject
> algorithms that don’t meet their security requirements.  Unless your
> application explicitly chooses to accept “alg”:”none”, the same code that
> would reject “alg”:”rot13” would reject “alg”:”none”.
>
> ** **
>
> If your application isn’t rejecting unacceptable algorithms, that’s an
> application bug – not a spec bug.
>
> ** **
>
>         -- Mike
>
> ** **
>
> *From:* Richard Barnes [mailto:r...@ipv.sx]
> *Sent:* Thursday, August 01, 2013 5:24 AM
> *To:* Mike Jones
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] Plaintext JWT bug
>
> ** **
>
> You don't view downgrade attacks as a compelling reason?
>
> ** **
>
> I look forward to your attempt to get this through SECDIR review.
>
> ** **
>
> On Thu, Aug 1, 2013 at 2:20 PM, Mike Jones 
> wrote:
>
> This is useful because it means that you can pass both unsigned and signed
> content using the same syntax, with no special parsing required.  This is
> used in practice, for instance, to enable both unsigned and signed request
> objects, signed and unsigned ID Tokens, etc.
>
>  
>
> This is already in widespread use.
>
>  
>
> I'm kind of surprised that this is coming up now.  This has been in JWT
> since March 2011 and in the JOSE specs since the working group versions, so
> it's not exactly a surprise.  (The biggest change was that we moved it from
> JWT to JWS in March 2012, at Jim Schaad's suggestion, because it is
> generally useful outside of just JWTs.)  Yes, an alternative syntax could
> have been used, but using the "alg":"none" value to express this works fine
> in practice.  I don't perceive a compelling reason to change it at this
> point.
>
>  
>
> -- Mike
>
>  
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, August 01, 2013 5:08 AM
> *To:* oauth@ietf.org WG
> *Subject:* [OAUTH-WG] Plaintext JWT bug
>
>  
>
> It has come to my attention that JWT is using "alg":"none" to create
> "Plaintext JWTs".  Some of us in JOSE believe that this "alg" value should
> be removed, because of a risk of downgrade attacks.  In order to do that, a
> suggested revision to JWT is below.  To summarize:
>
> -- Plaintext JWTs are not JWSs.  
>
> -- They just have a header and payload (separated by a '.')
>
> -- The header MUST NOT contain "alg", since there's no crypto going on
>
>  
>
> Thanks,
>
> --Richard
>
>  
>
>  
>
> -BEGIN-
>
> 6.  Plaintext JWTs
>
>  
>
>To support use cases where the JWT content is secured by a means
>
>other than a signature and/or encryption contained within the JWT
>
>(such as a signature on a data structure containing the JWT), JWTs
>
>MAY also be created without a signature or encryption.  A plaintext
>
>JWT is the concatenation of a base64url-encoded JWT Header, a 
>
>period ('.') character, and the base64url-encoded JWT Claims Set.
>
>  
>
>The header of a plaintext JWT contains parameters drawn from the 
>
>set as the JWS header.  However, a JWT header MUST NOT contain an
>
>"alg" header parameter, since no cryptographic processing is being
>
>performed.
>
>  
>
> 6.1.  Example Plaintext JWT
>
>  
>
>The following example JWT Header declares that the encoded object is***
> *
>
>a Plaintext JWT:
>
>  
>
>  {"typ":"JWT"}
>
>  
>
>Base64url encoding the octets of the UTF-8 representation of the JWT***
> *
>
>Header yields this Encoded JWT Header:
>
>  
>
>  eyJ0eXAiOiJKV1QifQ
>
>  
>
>The following is an example of a JWT Claims Set:
>
>  
>
>  {"iss":"joe",
>
>   "exp":1300819380,
>
>   "http://example.com/is_root":true}
>
>  
>
>Base64url encoding the octets of the UTF-8 represen

Re: [OAUTH-WG] Plaintext JWT bug

[Richard Barnes]

You don't view downgrade attacks as a compelling reason?

I look forward to your attempt to get this through SECDIR review.


On Thu, Aug 1, 2013 at 2:20 PM, Mike Jones wrote:

>  This is useful because it means that you can pass both unsigned and
> signed content using the same syntax, with no special parsing required.
> This is used in practice, for instance, to enable both unsigned and signed
> request objects, signed and unsigned ID Tokens, etc.
>
> ** **
>
> This is already in widespread use.
>
> ** **
>
> I'm kind of surprised that this is coming up now.  This has been in JWT
> since March 2011 and in the JOSE specs since the working group versions, so
> it's not exactly a surprise.  (The biggest change was that we moved it from
> JWT to JWS in March 2012, at Jim Schaad's suggestion, because it is
> generally useful outside of just JWTs.)  Yes, an alternative syntax could
> have been used, but using the "alg":"none" value to express this works fine
> in practice.  I don't perceive a compelling reason to change it at this
> point.
>
> ** **
>
>     -- Mike
>
> ** **
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, August 01, 2013 5:08 AM
> *To:* oauth@ietf.org WG
> *Subject:* [OAUTH-WG] Plaintext JWT bug
>
> ** **
>
> It has come to my attention that JWT is using "alg":"none" to create
> "Plaintext JWTs".  Some of us in JOSE believe that this "alg" value should
> be removed, because of a risk of downgrade attacks.  In order to do that, a
> suggested revision to JWT is below.  To summarize:
>
> -- Plaintext JWTs are not JWSs.  
>
> -- They just have a header and payload (separated by a '.')
>
> -- The header MUST NOT contain "alg", since there's no crypto going on
>
> ** **
>
> Thanks,
>
> --Richard
>
> ** **
>
> ** **
>
> -BEGIN-
>
> 6.  Plaintext JWTs
>
> ** **
>
>To support use cases where the JWT content is secured by a means
>
>other than a signature and/or encryption contained within the JWT
>
>(such as a signature on a data structure containing the JWT), JWTs
>
>MAY also be created without a signature or encryption.  A plaintext
>
>JWT is the concatenation of a base64url-encoded JWT Header, a 
>
>period ('.') character, and the base64url-encoded JWT Claims Set.
>
> ** **
>
>The header of a plaintext JWT contains parameters drawn from the 
>
>set as the JWS header.  However, a JWT header MUST NOT contain an
>
>"alg" header parameter, since no cryptographic processing is being
>
>performed.
>
> ** **
>
> 6.1.  Example Plaintext JWT
>
> ** **
>
>The following example JWT Header declares that the encoded object is***
> *
>
>a Plaintext JWT:
>
> ** **
>
>  {"typ":"JWT"}
>
> ** **
>
>Base64url encoding the octets of the UTF-8 representation of the JWT***
> *
>
>Header yields this Encoded JWT Header:
>
> ** **
>
>  eyJ0eXAiOiJKV1QifQ
>
> ** **
>
>The following is an example of a JWT Claims Set:
>
> ** **
>
>  {"iss":"joe",
>
>   "exp":1300819380,
>
>   "http://example.com/is_root":true}
>
> ** **
>
>Base64url encoding the octets of the UTF-8 representation of the JWT***
> *
>
>Claims Set yields this Encoded JWS Payload (with line breaks for
>
>display purposes only):
>
> ** **
>
>  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
>
>  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
>
> ** **
>
>Concatenating these parts in this order with aperiod ('.') character***
> *
>
>between the parts yields this complete JWT (with line breaks for
>
>display purposes only):
>
> ** **
>
>  eyJ0eXAiOiJKV1QifQ
>
>  .
>
>  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
>
>  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
>
>  
>
> ** **
>
> -END-
>
> ** **
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Plaintext JWT bug

[Richard Barnes]

It has come to my attention that JWT is using "alg":"none" to create
"Plaintext JWTs".  Some of us in JOSE believe that this "alg" value should
be removed, because of a risk of downgrade attacks.  In order to do that, a
suggested revision to JWT is below.  To summarize:
-- Plaintext JWTs are not JWSs.
-- They just have a header and payload (separated by a '.')
-- The header MUST NOT contain "alg", since there's no crypto going on

Thanks,
--Richard


-BEGIN-
6.  Plaintext JWTs

   To support use cases where the JWT content is secured by a means
   other than a signature and/or encryption contained within the JWT
   (such as a signature on a data structure containing the JWT), JWTs
   MAY also be created without a signature or encryption.  A plaintext
   JWT is the concatenation of a base64url-encoded JWT Header, a
   period ('.') character, and the base64url-encoded JWT Claims Set.

   The header of a plaintext JWT contains parameters drawn from the
   set as the JWS header.  However, a JWT header MUST NOT contain an
   "alg" header parameter, since no cryptographic processing is being
   performed.

6.1.  Example Plaintext JWT

   The following example JWT Header declares that the encoded object is
   a Plaintext JWT:

 {"typ":"JWT"}

   Base64url encoding the octets of the UTF-8 representation of the JWT
   Header yields this Encoded JWT Header:

 eyJ0eXAiOiJKV1QifQ

   The following is an example of a JWT Claims Set:

 {"iss":"joe",
  "exp":1300819380,
  "http://example.com/is_root":true}

   Base64url encoding the octets of the UTF-8 representation of the JWT
   Claims Set yields this Encoded JWS Payload (with line breaks for
   display purposes only):

 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
 cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

   Concatenating these parts in this order with aperiod ('.') character
   between the parts yields this complete JWT (with line breaks for
   display purposes only):

 eyJ0eXAiOiJKV1QifQ
 .
 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
 cGxlLmNvbS9pc19yb290Ijp0cnVlfQ


-END-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT)

[Richard Barnes]

Great, thanks!  I have cleared.
--Richard


On Sat, Jul 13, 2013 at 9:30 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

>  Hi Richard,
>
> thanks for your proposals. I adopted the draft accordingly.
>
> http://www.ietf.org/id/draft-ietf-oauth-revocation-11.txt
>
> regards,
> Torsten.
>
> Am 12.07.2013 20:43, schrieb Richard Barnes:
>
> Hi Torsten,
>
>  Sorry for the delay on this.  I've cleared on D2.  Focusing this
> response on point D1:
>
>
>   --
>>> DISCUSS:
>>> --
>>>
>>> D1. The mandate for TLS usage actually seems backward here.  Suppose a
>>> server receives a request over HTTP.  At this point, the credentials have
>>> been exposed, so you would *want* the token to be invalidated!  Suggest:
>>> -- Clients MUST NOT send over HTTP
>>> -- Server revocation URIs MUST be HTTPS
>>> -- Servers MAY support HTTP to the corresponding URI, just in case the
>>> client screws up
>>>
>>
>>  I see your point. Doesn't the last bullet contradict the first bullet?
>
>
>  They don't contradict each other; the third just assumes that the first
> might not be universally true.  But I would probably be happy with just the
> first two.
>
>  The scenario I'm worried about is the following:
>
>  1. An operator runs both HTTP and HTTPS servers under the name "
> example.com".  The HTTPS server is used for OAuth things, while the HTTP
> server for unsecured, public-facing things.  In particular, the revocation
> URIs the server hands out point to the HTTPS server.
>
>  2. An attack or mishap manages to change the revocation URL from
> "https:" to "http:"
>
>  3. When the client tries to revoke his token, he is able to successfully
> open a TCP connection to the HTTP server.  He then sends his revocation
> request over the TCP connection.
>
>  What is the safe thing for the server do now?  The client has exposed
> the token on the wire, so clearly it *should* be revoked.  But if the OAuth
> revocation service is only active on the HTTPS server, then it won't be.
>
>  In the spec, there are two things we can do, (1) try to prevent this
> scenario from happening, and (2) have it fail safely when it does happen.
>  In the above three suggested points, the first does (1) and the third does
> (2).  The document currently says that the server MUST require TLS (the
> second bullet above).  But that doesn't prevent the client from sending
> TLS, so it doesn't prevent the scenario.
>
>  Concrete suggestion to realize (1):
> OLD: "This URL MUST conform to the rules given in [RFC6749], section 3.1."
> NEW: "This URL MUST conform to the rules given in [RFC6749], section 3.1.
>  Clients MUST verify that the URL is an HTTPS URL."
>
>  Concrete suggestion to realize (2):
> OLD:
> """
>  Since requests to the token revocation endpoint result in the
> transmission of plain text credentials in the HTTP request, the
> authorization server MUST require the use of a transport-layer security
> mechanism when sending requests to the token revocation endpoints.
>  """
> NEW:
> """
> Since requests to the token revocation endpoint result in the transmission
> of plain text credentials in the HTTP request, URLs for token revocation
> endpoints MUST be HTTPS URLs.  If the host of the token revocation endpoint
> can also be reached over HTTP, then the server SHOULD also offer a
> revocation service at the corresponding HTTP URI, but MUST NOT publish this
> URI as a token revocation endpoint.  This ensures that tokens accidentally
> sent over HTTP will be revoked.
>  """
>
>
>
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT)

[Richard Barnes]

Hi Torsten,

Sorry for the delay on this.  I've cleared on D2.  Focusing this response
on point D1:


 --**--**--
>> DISCUSS:
>> --**--**
>> --
>>
>> D1. The mandate for TLS usage actually seems backward here.  Suppose a
>> server receives a request over HTTP.  At this point, the credentials have
>> been exposed, so you would *want* the token to be invalidated!  Suggest:
>> -- Clients MUST NOT send over HTTP
>> -- Server revocation URIs MUST be HTTPS
>> -- Servers MAY support HTTP to the corresponding URI, just in case the
>> client screws up
>>
>
> I see your point. Doesn't the last bullet contradict the first bullet?


They don't contradict each other; the third just assumes that the first
might not be universally true.  But I would probably be happy with just the
first two.

The scenario I'm worried about is the following:

1. An operator runs both HTTP and HTTPS servers under the name "example.com".
 The HTTPS server is used for OAuth things, while the HTTP server for
unsecured, public-facing things.  In particular, the revocation URIs the
server hands out point to the HTTPS server.

2. An attack or mishap manages to change the revocation URL from "https:"
to "http:"

3. When the client tries to revoke his token, he is able to successfully
open a TCP connection to the HTTP server.  He then sends his revocation
request over the TCP connection.

What is the safe thing for the server do now?  The client has exposed the
token on the wire, so clearly it *should* be revoked.  But if the OAuth
revocation service is only active on the HTTPS server, then it won't be.

In the spec, there are two things we can do, (1) try to prevent this
scenario from happening, and (2) have it fail safely when it does happen.
 In the above three suggested points, the first does (1) and the third does
(2).  The document currently says that the server MUST require TLS (the
second bullet above).  But that doesn't prevent the client from sending
TLS, so it doesn't prevent the scenario.

Concrete suggestion to realize (1):
OLD: "This URL MUST conform to the rules given in [RFC6749], section 3.1."
NEW: "This URL MUST conform to the rules given in [RFC6749], section 3.1.
 Clients MUST verify that the URL is an HTTPS URL."

Concrete suggestion to realize (2):
OLD:
"""
Since requests to the token revocation endpoint result in the transmission
of plain text credentials in the HTTP request, the authorization server
MUST require the use of a transport-layer security mechanism when sending
requests to the token revocation endpoints.
"""
NEW:
"""
Since requests to the token revocation endpoint result in the transmission
of plain text credentials in the HTTP request, URLs for token revocation
endpoints MUST be HTTPS URLs.  If the host of the token revocation endpoint
can also be reached over HTTP, then the server SHOULD also offer a
revocation service at the corresponding HTTP URI, but MUST NOT publish this
URI as a token revocation endpoint.  This ensures that tokens accidentally
sent over HTTP will be revoked.
"""
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

[Richard Barnes]

On the other hand, if you've already got a JSON or XML library on hand  
(as many apps these days do), then JSON/XML is a lot easier to handle  
than form-encoded.  Plus, if you're not re-using form-encoding, then  
there's no risk of being confused with actual "forms" / request  
parameters.  Not trying to argue one side or the other, just noting  
that there are trade-offs.


To refine Eran's point a little, how about this proposal?
1. Define N encodings of the OAuth parameters
2. Require servers to support *all* encodings
3. Require clients to support *one* encoding (and to send only one at  
a time!)

4. Require servers to respond in the encoding they receive

Seems like that would minimize the burden on clients, without placing  
a huge burden on servers.


--Richard



On Apr 19, 2010, at 3:37 PM, Mike Moore wrote:

On Mon, Apr 19, 2010 at 1:03 PM, Torsten Lodderstedt > wrote:


So what should be the singlemost encoding to be standardized? I  
would be unable to choose one.


I think form encoding is just fine. Its lightweight, minimalistic,  
and easy to implement. I don't see a reason to switch from the 1.0  
spec.


If the issue is poor implementations or devs not reading the spec,  
then perhaps we should discuss a series of executable specs or a  
reference implementation. (I know I sure could have used that when I  
implemented OAuth.) Just my two cents.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Rename callback => callback_uri

[Richard Barnes]

Ok, I think I get it.  Thanks for the explanation.

It seems we have a collision of layers here!  When OAuth parameters  
are being passed as request parameters (GET or POST), they can collide  
with parameters being used by an application (e.g., for JSONP).  In  
effect, encoding OAuth in this way creates a set of "reserved words"  
that applications can't use.


In the short run, it's probably an OK hack to rename parameters to  
something unlikely to collide, e.g., "oauth_*".  (Note: This applies  
to all OAuth parameters, not just "callback").


In the long run, though, doesn't this problem kind of argue that we  
shouldn't be passed as application-layer things (request parameters),  
but rather as HTTP-layer things, e.g., in an Authorization header?


--Richard



On Apr 16, 2010, at 3:05 PM, Evan Gilbert wrote:

We should use the same name in the User-Agent and Web Callback  
flows. Also, although the authorization server won't be allowing  
JSONP requests, "callback" has become a bit of a defacto standard  
for JSONP and it would be nice to use a term that isn't overloaded?


Can we make them both "redirection"? Even better, maybe  
"redirect_uri"?


On Fri, Apr 16, 2010 at 9:50 AM, Luke Shepard  
 wrote:
Facebook API requests are protected resources. They can be called  
either in a browser or in a server-to-server environment.


For example, a JSONP call for my name looks like this:

   
https://api.facebook.com/restserver.php?api_key=361900759629&call_id=1271436355034&callback=FB.RestServer._callback&format=json&method=fql.query&query=SELECT%20name%20FROM%20user%20WHERE%20uid%3D2901279&v=1.0

The output (you can play with it here: http://fbrell.com/fb.api/everyone-data 
 ):


   FB.RestServer._callback([{"name":"Luke Shepard"}]);

If we want that protected resource to take an access token as well,  
then it would look like:


   
https://api.facebook.com/restserver.php?&callback=FB.RestServer._callback&access_token=ACCESS_TOKEN

The "callback" parameter is used pretty universally for JSONP  
requests. For instance, see the Jquery docs: http://api.jquery.com/jQuery.getJSON/


-Original Message-
From: Richard Barnes [mailto:rbar...@bbn.com]
Sent: Friday, April 16, 2010 9:10 AM
To: Luke Shepard
Cc: Eran Hammer-Lahav; Naitik Shah; OAuth WG
Subject: Re: [OAUTH-WG] Rename callback => callback_uri

Could you clarify a little more the environment in which this
confusion arose?  What do you mean when you say "The protected
resource typically accepts 'callback' as a parameter to support
JSONP."?  What sort of software are you including in this?

--Richard


On Apr 15, 2010, at 5:41 PM, Luke Shepard wrote:

> We already had one developer try it out and get confused because the
> server tried to treat the callback URL as a JSONP callback.
>
> The protected resource typically accepts "callback" as a parameter
> to support JSONP. If a developer accidentally passes in callback
> there (maybe they got confused) then the server can't give a normal
> error message - instead it needs to either detect that it looks like
> a URL or otherwise reject it.
>
> On a related note, I think it's more confusing calling it something
> different in the user-agent flow (redirector) when it's essentially
> doing the same thing.
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> Behalf Of Eran Hammer-Lahav
> Sent: Thursday, April 15, 2010 5:37 AM
> To: Naitik Shah; OAuth WG
> Subject: Re: [OAUTH-WG] Rename callback => callback_uri
>
> I don't think it is that confusing. Its a completely different
> context from where JSON-P is used (note that in the User-Agent flow
> it is called something else).
>
> EHL
>
>
> On 4/10/10 12:35 PM, "Naitik Shah"  wrote:
>
> With the simplified params, the callback url parameter is now just
> "callback". Since most major API providers already use "callback" to
> signify JSON-P callback, can we rename this to "callback_uri"? This
> will help avoid collisions and confusion.
>
>
> -Naitik
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Rename callback => callback_uri

[Richard Barnes]

Could you clarify a little more the environment in which this  
confusion arose?  What do you mean when you say "The protected  
resource typically accepts 'callback' as a parameter to support  
JSONP."?  What sort of software are you including in this?


--Richard


On Apr 15, 2010, at 5:41 PM, Luke Shepard wrote:

We already had one developer try it out and get confused because the  
server tried to treat the callback URL as a JSONP callback.


The protected resource typically accepts “callback” as a parameter  
to support JSONP. If a developer accidentally passes in callback  
there (maybe they got confused) then the server can’t give a normal  
error message – instead it needs to either detect that it looks like  
a URL or otherwise reject it.


On a related note, I think it’s more confusing calling it something  
different in the user-agent flow (redirector) when it’s essentially  
doing the same thing.



From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On  
Behalf Of Eran Hammer-Lahav

Sent: Thursday, April 15, 2010 5:37 AM
To: Naitik Shah; OAuth WG
Subject: Re: [OAUTH-WG] Rename callback => callback_uri

I don’t think it is that confusing. Its a completely different  
context from where JSON-P is used (note that in the User-Agent flow  
it is called something else).


EHL


On 4/10/10 12:35 PM, "Naitik Shah"  wrote:

With the simplified params, the callback url parameter is now just  
"callback". Since most major API providers already use "callback" to  
signify JSON-P callback, can we rename this to "callback_uri"? This  
will help avoid collisions and confusion.



-Naitik
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Issue: add refresh token as optional in all access token requests

[Richard Barnes]

Sure, this seems sensible, especially with the *optional* part.



On Apr 15, 2010, at 3:22 PM, David Recordon wrote:


+1, remember discussing this a week or so ago on the list

On Thu, Apr 15, 2010 at 12:12 PM, Eran Hammer-Lahav > wrote:

Not all the flows return a refresh token for security or practicality
reasons. Adding refresh token as optional in all access token  
requests is
required to enable upgrading a token to a token with secret. It  
also can
make the spec slightly shorter by not having to repeat all the  
parameters.


We need to either add it to every token response or allow the  
client to

request a secret directly without having to refresh the token.

Proposal: Keep bearer tokens as the default first-issued credential  
and add

an optional refresh token everywhere.

EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shorter authorization endpoint type names

[Richard Barnes]

Why do we need to label the requests according to which flow they  
belong to?


Apologies if this is a dumb question; haven't read the latest draft.


On Apr 15, 2010, at 1:31 PM, Eran Hammer-Lahav wrote:


I renamed the values of the 'type' parameter as follows:

WC-A: web_callback_access_request
WC-T: web_callback_token_request
NA-A: native_app_access_request
NA-T: native_app_token_request
UA-A: user_agent_request
DV-A: device_access_request
DV-T: device_token_request
UP-T: username_password_request
CC-T: client_cred_request
AS-T: assertion_request

R-T: refresh_token


EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cache-control for Authorization server

[Richard Barnes]

This argument makes sense to me.

EHL: Do you have an exception in mind?



On Apr 14, 2010, at 10:15 AM, Jeroen van Bemmel wrote:

Since HTTPS is used, intermediate proxies aren't a problem. However,  
a browser might store the response containing the token in  
"Temporary Internet files" or similar locations, and rich clients  
often use the same HTTP libraries as the browser. Since the server  
cannot make any assumptions about which software is being used on  
the client side, we have to assume the worst - hence 'MUST' to  
reduce the chance of tokens being exposed to other programs /  
malware running on the same machine


Of course this still does not guarantee that tokens don't get stored/ 
cached in insecure places, but it reduces the likelihood.


Regards,
Jeroen

On 13-4-2010 17:22, Eran Hammer-Lahav wrote:


Is this really a MUST?

EHL


On 4/13/10 7:23 AM, "jbem...@zonnet.nl"  wrote:

All,

I think the draft should explicitly state that the Authorization  
server

MUST use Cache-Control: no-store on all responses that contain tokens
or other sensitive information, since this is critical to the  
security

properties of the protocol

Regards,
Jeroen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

[Richard Barnes]

Certainly it should be recommended that bearer tokens have limited  
scope, but because the notion of "limited scope" isn't well-defined,  
you can't really say that "bearer tokens MUST have limited scope".   
When it comes to the *normative* text (i.e., the stuff in capital  
letters), we need to cover the general case, which requires the "MUST  
implement security, SHOULD use security" pattern.  Language about  
scope is complementary to this.


--Richard



On Apr 8, 2010, at 5:20 PM, John Kemp wrote:


On Apr 8, 2010, at 4:58 PM, Richard Barnes wrote:

The scope argument doesn't really hold any water, since OAuth isn't  
defining the scope that tokens have -- authorization servers could  
issue tokens that have the same power as passwords.  Not all  
implementors are "reasonable" :)


Indeed, you can't ever stop people doing stupid things.

But the "scope argument" (and expiration time) does certainly hold  
water. Bearer tokens that have appropriate limitations on usage are  
well-known to be useful (see one-time use, or time-limited URLs --  
for confirming email subscriptions, for example). Such conditions on  
usage are useful irrespective of whether you believe that tokens  
should be sent only over SSL/TLS.


Regards,

- johnk



--Richard



On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:

Using a bearer token without a signature over HTTP is not  
equivalent to HTTP Basic Auth in the clear.


A bearer token is far less powerful than the user’s password.  In  
most cases, a MITM who steals the user’s password would be able to  
change the user’s password, locking the user out his account.  
Passwords are not scoped and allow full access to the user’s  
account.


A bearer token (for all reasonable implementations) would never  
let the holder change the user’s password. Although we have not  
standardized on the concept of scope, presumably, many  
implementers will issue Access Tokens that do not grant access to  
the entirety of the user’ account.


Another important difference between OAuth2 Access Tokens and HTTP  
Basic Auth is that Access Tokens can have a limited lifetime, so a  
MITM would only be able to hijack an Access Token for a short  
duration.


My recommendation is that the spec recommend that Service  
Providers use HTTPS for enhanced security, however in the cases  
where using HTTPS is not feasible or desirable, Services Providers  
should do one or more of the following:


	• Issue access tokens that are less powerful than the user’s  
password

• Use signatures
	• Issue access tokens with a short lifetime, and use the Refresh  
workflow


Allen




On 4/7/10 11:06 PM, "Eran Hammer-Lahav"  wrote:


How about something like this:

When accessing resources using the http URI scheme, clients  
SHOULD NOT use and servers SHOULD NOT accept bearer token  
requests (unsigned requests) as such a request is equal to  
sending unprotected credentials in the clear. Instead, clients  
SHOULD obtain and utilize an access token with a matching secret  
by sending a signed request. Servers MUST accept signed requests  
for protected resources using the http URI scheme.


EHL




On 4/7/10 6:42 PM, "Richard Barnes"  wrote:

You guys are both right: The recommendation I made before is  
basically

saying that you SHOULD only use tokens without signing on HTTPS
resources.

--Richard


On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:


Eran

Richard and Lief are describing the same point we had in the past
where Peter surmised the discussion that an *implementation* MUST
support TLS is required for bearer tokens to be compliant, and  
that

TLS is recommended for *deployment*

-- Dick

On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:


We are looking at this all wrong.

There are two kinds of protected resources OAuth supports:

* http://
* https://

OAuth provides two kinds of token authentication modes:

* bearer token
* token + signature

I don't know how to translate your statement below into text I  
can

put in
the draft to answer:

When you access/serve an http:// protected resource you do what?
When you access/serve an https:// protected resource you do  
what?


It is not about requiring SSL for bearer token. It is about  
what you

can/should do when accessing an http:// resource.

EHL

On 4/7/10 7:09 AM, "Richard Barnes"  wrote:

To re-iterate and clarify Leif's second point, I would be in  
favor

of
making TLS:

-- REQUIRED for implementations to support (== MUST)
-- RECOMMENDED for deployments to use (== SHOULD)

This a pretty universal pattern in IETF protocols.

--Richard


On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:




Go implement whatever you want. But the spec should set the
highest
practical bar it can, and requiring HTTPS is trivial.

As a practical note, if the WG reaches consensus to drop  
the MUST,

I would
ask the chairs to ask the security

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

[Richard Barnes]

That looks fine to me.


On Apr 8, 2010, at 2:06 AM, Eran Hammer-Lahav wrote:


How about something like this:

When accessing resources using the http URI scheme, clients SHOULD  
NOT use and servers SHOULD NOT accept bearer token requests  
(unsigned requests) as such a request is equal to sending  
unprotected credentials in the clear. Instead, clients SHOULD obtain  
and utilize an access token with a matching secret by sending a  
signed request. Servers MUST accept signed requests for protected  
resources using the http URI scheme.


EHL




On 4/7/10 6:42 PM, "Richard Barnes"  wrote:

You guys are both right: The recommendation I made before is basically
saying that you SHOULD only use tokens without signing on HTTPS
resources.

--Richard


On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:

> Eran
>
> Richard and Lief are describing the same point we had in the past
> where Peter surmised the discussion that an *implementation* MUST
> support TLS is required for bearer tokens to be compliant, and that
> TLS is recommended for *deployment*
>
> -- Dick
>
> On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:
>
>> We are looking at this all wrong.
>>
>> There are two kinds of protected resources OAuth supports:
>>
>> * http://
>> * https://
>>
>> OAuth provides two kinds of token authentication modes:
>>
>> * bearer token
>> * token + signature
>>
>> I don't know how to translate your statement below into text I can
>> put in
>> the draft to answer:
>>
>> When you access/serve an http:// protected resource you do what?
>> When you access/serve an https:// protected resource you do what?
>>
>> It is not about requiring SSL for bearer token. It is about what  
you

>> can/should do when accessing an http:// resource.
>>
>> EHL
>>
>> On 4/7/10 7:09 AM, "Richard Barnes"  wrote:
>>
>>> To re-iterate and clarify Leif's second point, I would be in favor
>>> of
>>> making TLS:
>>>
>>> -- REQUIRED for implementations to support (== MUST)
>>> -- RECOMMENDED for deployments to use (== SHOULD)
>>>
>>> This a pretty universal pattern in IETF protocols.
>>>
>>> --Richard
>>>
>>>
>>> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:
>>>
>>>>
>>>>> Go implement whatever you want. But the spec should set the
>>>>> highest
>>>>> practical bar it can, and requiring HTTPS is trivial.
>>>>>
>>>>> As a practical note, if the WG reaches consensus to drop the  
MUST,

>>>>> I would
>>>>> ask the chairs to ask the security area and IESG to provide
>>>>> guidance whether
>>>>> they would approve such document. The IESG did not approve OAuth
>>>>> 1.0a for
>>>>> publication as an RFC until this was changed to a MUST (for
>>>>> PLAINTEXT) among
>>>>> other comments, and that with a strong warning.
>>>>>
>>>>> There is also an on going effort to improve cookie security.  
Do we

>>>>> really
>>>>> want OAuth to become the next weakest link?
>>>>
>>>> I emphatically agree.
>>>>
>>>> I suspect that a lot of confusion on this thread is caused by
>>>> confusing implementation requirements with deployment  
requirements

>>>> btw.
>>>>
>>>> Cheers Leif
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

[Richard Barnes]

The scope argument doesn't really hold any water, since OAuth isn't  
defining the scope that tokens have -- authorization servers could  
issue tokens that have the same power as passwords.  Not all  
implementors are "reasonable" :)


--Richard



On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:

Using a bearer token without a signature over HTTP is not equivalent  
to HTTP Basic Auth in the clear.


A bearer token is far less powerful than the user’s password.  In  
most cases, a MITM who steals the user’s password would be able to  
change the user’s password, locking the user out his account.  
Passwords are not scoped and allow full access to the user’s account.


A bearer token (for all reasonable implementations) would never let  
the holder change the user’s password. Although we have not  
standardized on the concept of scope, presumably, many implementers  
will issue Access Tokens that do not grant access to the entirety of  
the user’ account.


Another important difference between OAuth2 Access Tokens and HTTP  
Basic Auth is that Access Tokens can have a limited lifetime, so a  
MITM would only be able to hijack an Access Token for a short  
duration.


My recommendation is that the spec recommend that Service Providers  
use HTTPS for enhanced security, however in the cases where using  
HTTPS is not feasible or desirable, Services Providers should do one  
or more of the following:


• Issue access tokens that are less powerful than the user’s password
• Use signatures
	• Issue access tokens with a short lifetime, and use the Refresh  
workflow


Allen




On 4/7/10 11:06 PM, "Eran Hammer-Lahav"  wrote:


How about something like this:

When accessing resources using the http URI scheme, clients SHOULD  
NOT use and servers SHOULD NOT accept bearer token requests  
(unsigned requests) as such a request is equal to sending  
unprotected credentials in the clear. Instead, clients SHOULD  
obtain and utilize an access token with a matching secret by  
sending a signed request. Servers MUST accept signed requests for  
protected resources using the http URI scheme.


EHL




On 4/7/10 6:42 PM, "Richard Barnes"  wrote:

You guys are both right: The recommendation I made before is  
basically

saying that you SHOULD only use tokens without signing on HTTPS
resources.

--Richard


On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:

> Eran
>
> Richard and Lief are describing the same point we had in the past
> where Peter surmised the discussion that an *implementation* MUST
> support TLS is required for bearer tokens to be compliant, and  
that

> TLS is recommended for *deployment*
>
> -- Dick
>
> On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:
>
>> We are looking at this all wrong.
>>
>> There are two kinds of protected resources OAuth supports:
>>
>> * http://
>> * https://
>>
>> OAuth provides two kinds of token authentication modes:
>>
>> * bearer token
>> * token + signature
>>
>> I don't know how to translate your statement below into text I  
can

>> put in
>> the draft to answer:
>>
>> When you access/serve an http:// protected resource you do what?
>> When you access/serve an https:// protected resource you do what?
>>
>> It is not about requiring SSL for bearer token. It is about  
what you

>> can/should do when accessing an http:// resource.
>>
>> EHL
>>
>> On 4/7/10 7:09 AM, "Richard Barnes"  wrote:
>>
>>> To re-iterate and clarify Leif's second point, I would be in  
favor

>>> of
>>> making TLS:
>>>
>>> -- REQUIRED for implementations to support (== MUST)
>>> -- RECOMMENDED for deployments to use (== SHOULD)
>>>
>>> This a pretty universal pattern in IETF protocols.
>>>
>>> --Richard
>>>
>>>
>>> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:
>>>
>>>>
>>>>> Go implement whatever you want. But the spec should set the
>>>>> highest
>>>>> practical bar it can, and requiring HTTPS is trivial.
>>>>>
>>>>> As a practical note, if the WG reaches consensus to drop the  
MUST,

>>>>> I would
>>>>> ask the chairs to ask the security area and IESG to provide
>>>>> guidance whether
>>>>> they would approve such document. The IESG did not approve  
OAuth

>>>>> 1.0a for
>>>>> publication as an RFC until this was changed to a MUST (for
>>>>> PLAINTEXT) among
>>>>> other comments, and that with a strong warning.
>>>>>
>>>>> There is also an on going e

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

[Richard Barnes]

You guys are both right: The recommendation I made before is basically  
saying that you SHOULD only use tokens without signing on HTTPS  
resources.


--Richard


On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:


Eran

Richard and Lief are describing the same point we had in the past  
where Peter surmised the discussion that an *implementation* MUST  
support TLS is required for bearer tokens to be compliant, and that  
TLS is recommended for *deployment*


-- Dick

On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:


We are looking at this all wrong.

There are two kinds of protected resources OAuth supports:

* http://
* https://

OAuth provides two kinds of token authentication modes:

* bearer token
* token + signature

I don't know how to translate your statement below into text I can  
put in

the draft to answer:

When you access/serve an http:// protected resource you do what?
When you access/serve an https:// protected resource you do what?

It is not about requiring SSL for bearer token. It is about what you
can/should do when accessing an http:// resource.

EHL

On 4/7/10 7:09 AM, "Richard Barnes"  wrote:

To re-iterate and clarify Leif's second point, I would be in favor  
of

making TLS:

-- REQUIRED for implementations to support (== MUST)
-- RECOMMENDED for deployments to use (== SHOULD)

This a pretty universal pattern in IETF protocols.

--Richard


On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:



Go implement whatever you want. But the spec should set the  
highest

practical bar it can, and requiring HTTPS is trivial.

As a practical note, if the WG reaches consensus to drop the MUST,
I would
ask the chairs to ask the security area and IESG to provide
guidance whether
they would approve such document. The IESG did not approve OAuth
1.0a for
publication as an RFC until this was changed to a MUST (for
PLAINTEXT) among
other comments, and that with a strong warning.

There is also an on going effort to improve cookie security. Do we
really
want OAuth to become the next weakest link?


I emphatically agree.

I suspect that a lot of confusion on this thread is caused by
confusing implementation requirements with deployment requirements
btw.

Cheers Leif
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

[Richard Barnes]

To re-iterate and clarify Leif's second point, I would be in favor of  
making TLS:


-- REQUIRED for implementations to support (== MUST)
-- RECOMMENDED for deployments to use (== SHOULD)

This a pretty universal pattern in IETF protocols.

--Richard


On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:




Go implement whatever you want. But the spec should set the highest
practical bar it can, and requiring HTTPS is trivial.

As a practical note, if the WG reaches consensus to drop the MUST,  
I would
ask the chairs to ask the security area and IESG to provide  
guidance whether
they would approve such document. The IESG did not approve OAuth  
1.0a for
publication as an RFC until this was changed to a MUST (for  
PLAINTEXT) among

other comments, and that with a strong warning.

There is also an on going effort to improve cookie security. Do we  
really

want OAuth to become the next weakest link?


I emphatically agree.

I suspect that a lot of confusion on this thread is caused by  
confusing implementation requirements with deployment requirements  
btw.


Cheers Leif
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Renaming expires to expires_in?

[Richard Barnes]

Ok, maybe something like "lifetime"?


On Apr 5, 2010, at 12:46 PM, Paul Lindner wrote:


+1

This would more closely match the nomenclature used by the oauth  
session extension.



On Mon, Apr 5, 2010 at 9:09 AM, David Recordon > wrote:
As one of our engineers was implementing a client, they got confused  
about what was being returned by the expires parameter. Anyone  
object to renaming it to expires_in so that it's clear that it isn't  
an absolute timestamp?


Thanks,
--David
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] A display parameter for user authorization requests

[Richard Barnes]

I guess I'm one of those IETF folks that likes to separate content  
from presentation :)


In any case, it seems like there's some agreement here that display  
parameters are something that should be optional / extension.  That's  
fine with me.


It sounds, though, like maybe what you want is a way to describe  
criteria?  (Rather than a set of tokens)  E.g., if you just passed in  
the x/y dimensions of the space that the authorization server would  
have available to it, then the server could customize the UI to that  
space.  Would that be enough for the use cases you have in mind?


--Richard




On Mar 30, 2010, at 6:16 PM, David Recordon wrote:

On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes   
wrote:
This seems rather application-specific.  What semantics do these  
things take
on when HTTP is just being used as a transport, e.g., for a virtual  
world

system (see VWRAP)?

Also, maybe I'm misunderstanding things here, but since it's the  
Client that
send the browser to the authorization page, doesn't the Client  
control how

the authorization page is displayed?  In an iframe, popup, etc...


Yes, but the Client needs to make sure that the authorization page
will fit in whatever constraints they're choosing.  This might be a
popup window but could also be a full page redirect.  There's also the
case in the Web Client flow where the Client just wants an immediate
response of yes/no (ala OpenID's checkid_immediate mode) versus
presenting any UI in the first request.


Perhaps what you want here is a set of different authorization URIs  
that
result in different appearances (e.g., desktop vs. mobile)?  You're  
already
assuming that the application developer knows which of these  
options he

wants.


There are a few ways to go about it:
1) different mainly duplicative versions of the Web Client and Web  
Server flows

2) multiple modes within the existing Web Client and Web Server flows
3) different user authorization endpoints which can be used with
either the Web Client or Web Server flow
4) an optional parameter like in this proposal

I'd rather have this be something more dynamic than multiple hard
coded user authorization URLs and duplicating flows seems more
confusing to developers.

--David


--Richard



On Mar 30, 2010, at 4:54 PM, David Recordon wrote:

One of the challenges we're running into from an implementation  
standpoint
is having the ability for a Client developer to tell the  
Authorization

Server if they're looking for a popup, full page redirect, mobile
experience, or no user interface for the times when a user is  
being sent
through an authorization flow.  We're thinking that an additional  
"display"
parameter would be useful within the Web Client and Web Server  
flows.

 Values would include none, page, popup, and mobile.

none - Mainly for the Web Client profile. The Authorization Server  
should
return an immediate response either as an error or an access token  
if the

user has already authorized the Client and has a current session.

popup - The Client is intending to display the Authorization  
Server's user
authorization flow within a popup window.  Negotiating size seems  
reasonable

to exclude from scope for now.

page - The Client is redirecting the user's browser to a page on the
Authorization Server.  (This is probably the default and could be  
unneeded.)


mobile - Force a mobile experience instead of the normal full page.

Most Clients will never need to use this parameter because it will
automatically work using the standard OAuth redirect, but  
developers can

override it and it's needed in the Web Client flow.

--David
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] A display parameter for user authorization requests

[Richard Barnes]

This seems rather application-specific.  What semantics do these  
things take on when HTTP is just being used as a transport, e.g., for  
a virtual world system (see VWRAP)?


Also, maybe I'm misunderstanding things here, but since it's the  
Client that send the browser to the authorization page, doesn't the  
Client control how the authorization page is displayed?  In an iframe,  
popup, etc...


Perhaps what you want here is a set of different authorization URIs  
that result in different appearances (e.g., desktop vs. mobile)?   
You're already assuming that the application developer knows which of  
these options he wants.


--Richard



On Mar 30, 2010, at 4:54 PM, David Recordon wrote:

One of the challenges we're running into from an implementation  
standpoint is having the ability for a Client developer to tell the  
Authorization Server if they're looking for a popup, full page  
redirect, mobile experience, or no user interface for the times when  
a user is being sent through an authorization flow.  We're thinking  
that an additional "display" parameter would be useful within the  
Web Client and Web Server flows.  Values would include none, page,  
popup, and mobile.


none - Mainly for the Web Client profile. The Authorization Server  
should return an immediate response either as an error or an access  
token if the user has already authorized the Client and has a  
current session.


popup - The Client is intending to display the Authorization  
Server's user authorization flow within a popup window.  Negotiating  
size seems reasonable to exclude from scope for now.


page - The Client is redirecting the user's browser to a page on the  
Authorization Server.  (This is probably the default and could be  
unneeded.)


mobile - Force a mobile experience instead of the normal full page.

Most Clients will never need to use this parameter because it will  
automatically work using the standard OAuth redirect, but developers  
can override it and it's needed in the Web Client flow.


--David
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

[Richard Barnes]

Allen,

Right, the PR needs to have the client's access token so that it knows  
which access tokens to accept.  The AS issues the access token, so in  
order for the PR to know the access token, the AS need to send a  
secure message to the PR saying that "this access token is OK".  This  
communication can happen either directly or indirectly:

-- Direct: AS tells PR which access tokens are valid
-- Indirect: AS signs access token

Either way, the PR has to be able to authenticate messages from the  
AS, so it has to have a public key or shared key for the AS.  That  
same key could be used to communicate keys to validate signatures from  
clients (access token secrets).


So disallowing signatures actually doesn't save you anything in terms  
of the crypto that the PR and AS need.


--Richard



On Mar 23, 2010, at 11:42 AM, Allen Tom wrote:


Hi Richard,

From a security perspective, it might be undesirable to distribute the
client secret to all potential protected resources that a client  
might want

to access.

In many ways, distributing the client secret to all PRs is  
undesirable in
the same way that it's undesirable to distribute the user's password  
to all
PRs. Even if the client secret is encrypted into the Access Token,  
it has to
be extracted by the PR to verify the signature (at least using the  
current

version of the Oauth 2.0 spec).

If the client secret is distributed to the PR, the PR would be able to
impersonate the client. (Unlike Oauth 1.0, the PR and the AuthZ  
server are

separate entities)

Admittedly, with Oauth-WRAP, the PR would still have a client's access
token, however, the access token could be scoped to be only valid  
for the
PR, so a PR might not be able to impersonate the client by replaying  
the

access token, and also the Access Token has a limited lifetime.

Hope that helps to clarify things,
Allen


On 3/22/10 10:19 PM, "Richard Barnes"  wrote:




If you make the same two assumptions -- shared keys and structured
tokens -- then the signing cases can also work via the token: You can
just encrypt the validation key (MAC key or public key) with the
shared key and put it in the token.

So from the perspective of the need for a relationship between AS and
PR, there is absolutely no difference between the "bearer token" and
"signing" use cases.

--Richard





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What error codes do you need?

[Richard Barnes]

Well, the relevant part says "200 or 500"; the basic message is that  
if your HTTP-using application has an error, but the HTTP was OK, then  
you shouldn't have an HTTP-layer error.  So for instance, in the  
GEOPRIV HELD protocol [1], every request returns 200 unless the HTTP  
is screwed up, and there's an  element that provides  
application-layer codes and explanations.


Again, this model might not make sense for OAuth, since OAuth is more  
tied into the HTTP layer than layered on top of it.  You could  
probably make a case for using 401/403 in this space, and maybe for  
some new codes.


--Richard

[1] http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery




On Mar 23, 2010, at 9:54 AM, John Panzer wrote:

That's an interesting and informative RFC, but it recommends using  
the 500 response code for all errors (unless I'm misreading).   
Errors due to incorrect input should be 4xx.


On Mon, Mar 22, 2010 at 10:02 PM, Richard Barnes   
wrote:
In case it's helpful, BCP 56 / RFC 3205 provides recommendations for  
using HTTP as a substrate for other protocols:


<https://tools.ietf.org/html/bcp56>
... in particular with respect to status codes:

<https://tools.ietf.org/html/bcp56#section-8>

It's worth thinking about how that document applies to OAuth, since  
the goal here isn't really necessariliy to use HTTP as a substrate,  
but rather to extend HTTP in certain ways.


--Richard




On Mar 22, 2010, at 10:56 AM, David Recordon wrote:

In drafting OAuth 2.0 I removed a lot of the error codes throughout
the flows and in this draft encouraged people to use HTTP status codes
(like 1.0a does).  I've heard the feedback from multiple people that
they'd like more specific error codes than what can be expressed in
HTTP.  I'd like to use this thread – or ideally a wiki page that
someone creates – to build consensus around the error codes needed
throughout protocol responses.

Is someone willing to take the lead on this?  http://wiki.oauth.net/
should be easy enough to create a new page on.

Thanks,
--David
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

[Richard Barnes]

Actually, Brian and I discussed this very topic at some length after  
the OAuth after-party today.  If you think about it, it is impossible  
to completely separate the Authz Server (AS) from the Protected  
Resource (PR) -- in all of the possible cases, the AS needs to be able  
to pass secure messages to the PR, in one form or another.


In the signing cases, this is obvious: The AS needs to provide the PR  
with a key to validate signatures (either a MAC key or a public key).   
However, it remains true even for bearer tokens, since the AS needs to  
communicate to the PR which tokens are valid tokens.  This  
communication needs to be secure, so that tokens can't be spoofed.


In either case (signing or bearer), secured validation information has  
to get passed from the AS to the PR.  Based on the phrase "validate  
Access Tokens", it sounds like you're already acknowledging that the  
token can have internal structure that constitutes a secure message  
from the AS (e.g., if token == request-uri + signature).  But even  
that assumes that the AS and the PR share a key pair (symmetric or  
asymmetric).


If you make the same two assumptions -- shared keys and structured  
tokens -- then the signing cases can also work via the token: You can  
just encrypt the validation key (MAC key or public key) with the  
shared key and put it in the token.


So from the perspective of the need for a relationship between AS and  
PR, there is absolutely no difference between the "bearer token" and  
"signing" use cases.


--Richard



On Mar 22, 2010, at 4:20 PM, Allen Tom wrote:


Hi All -

Regarding the client secret - one of the design goals for OAuth-WRAP  
was to
cleanly separate the AuthZ server from the Protected Resource. The  
Protected
Resource should only have to know how to validate Access Tokens  
issued by

its AuthZ server.

The HMAC-SHA1 signature method defined in 4.2.1.1 of the Oauth 2.0  
spec
violates this principle because it requires the protected resource  
to have

the client secret in order to validate the signature. Distributing the
client secret to all Protected Resources can have negative security  
and

performance implications.

http://www.ietf.org/mail-archive/web/oauth/current/msg01396.html#compute_sig

I recommend removing the client secret from the signature  
calculation, and

instead using only the Access Token secret.

Allen




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What error codes do you need?

[Richard Barnes]

In case it's helpful, BCP 56 / RFC 3205 provides recommendations for  
using HTTP as a substrate for other protocols:


... in particular with respect to status codes:


It's worth thinking about how that document applies to OAuth, since  
the goal here isn't really necessariliy to use HTTP as a substrate,  
but rather to extend HTTP in certain ways.


--Richard



On Mar 22, 2010, at 10:56 AM, David Recordon wrote:


In drafting OAuth 2.0 I removed a lot of the error codes throughout
the flows and in this draft encouraged people to use HTTP status codes
(like 1.0a does).  I've heard the feedback from multiple people that
they'd like more specific error codes than what can be expressed in
HTTP.  I'd like to use this thread – or ideally a wiki page that
someone creates – to build consensus around the error codes needed
throughout protocol responses.

Is someone willing to take the lead on this?  http://wiki.oauth.net/
should be easy enough to create a new page on.

Thanks,
--David
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth