Tuesday March 28, 2023
https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-chairs-update-01
two meetings this week -- today and friday
side meetings: none this time
Roman: it's inappropriate to hold effectively working group meetings
during side-meeting time
RFC updates: RAR and JWT for token introspection
Pub requested: DPoP & step-up authn
waiting for shepherd🐑: security BCP
Daniel: we have a couple editorial things
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-sessb-sd-jwt
Daniel: please read the SD-JWT draft.
simple standard to provide selective disclosure; shortest path, using
standard crypto (salted hash-based)
We hope the current verison looks like this.
sd-jwt in five steps:
create disclosures
hash claims and put the values there instead of original claims
What do we do with that?
The issuer produces the sd-jwt and disclosures, and transfers this stuff
to the holder of the credential.
The holder or end user then presents the credential, and some
disclosures to a verifier, only the ones needed by the verifier
If desired the holder can provide a bind JWT, to the verifier as well,
which is based on a key commited to the credential by the original
issuer.
The verifier checks the signarure of the SD-JWT, confirming it comes
from the issuer.
The verfier then hashes the disclosures and discovers if they are
present in the original credential.
This means any generic implementation must implement the hash.
The verifier also checks the holder binding if present.
We have had format changes since the last IETF meeting.
We now allow nested disclosures, this supports nested objects, which
is very natural.
This change enables sd-jwts with fine granularity, and makes the
algorithms easier to implement.
We also added an example that features JSON-LD to support the W3C
Verifiable Credential use case.
We also added privacy considerations for holder binding and other
details.
Kristina: The point of the JSON-LD example, shows that any JSON can be
used as the payload, and JSON-LD is just one example.
We will cover 3 discussion points:
SD-JWT is not JWS.
The processing rules are different, even if some libraries can be
reused.
We need to be able to distinguish between types.
What about application/jwt use case? can we signal that it is an sd-jwt?
JWT BCP recommends specific types (typ)
potentially a media types for the payload as well (cty)
Also consideration of JWE wrapper on SD-JWT, cty would be useful for
this use case.
also, considering full disclosure (issuance) or selective disclosure
(presentation)
Should we reserve the structured suffix for sd-jwt ?
There is a PR that attempts to clarify structure, please review.
Orie: in favor of specific typing and reserving structured suffix
Mike: it would be logical to use application/sd+jwt for (typ)
Orie: clarifying, you want sd+jwt not sd-jwt?
Mike: yes
Mike P: esp. after having sat through mediaman, structured suffix could
be problematic
Krstina: I have opinions, lets discsuss later.
Consider dislosuing a single element of an array.
We think its possible, we have a proposal, but do we need it?
Do you have a use case or need in the market, for disclosing array
elements?
First propsoal: Receiver of an sd-jwt will need to distinnguish array of
hashes from plain text... so we need to signal that difference.
We could use prefixing / namespacing to suppport this.
Torsten: We have experimented with education credentials and sd-jwt, so
we have use cases for achievements that use arrays, we really appreciate
the work on arrays.
Gulan Wang: How does the disclosure scheme work?
Daniel: it's simple; hash the plaintext, sign over the hash
Gulan Wang: What about group signatures? They are more complex.
Kristina: you can use whatever JWS signatures support
Tobias: For the array elements, what datatypes would be supported in the
arrays? numbers, strings, objects?
Daniel: the disclosure will work the same way, but the hash takes the
place of the value.
Tobias: Unless you consistently validate all the array elements, there
might be issues.
Daniel: There are trade offs.
Kristina: Jades from europe could use a JSON serailization.
Daniel has a proposal, where payload an disclosures are seperate
members.
Another approach would be to use base64url encoding.
The first appraoch is cleaner, and uses less encoding.
But the second one uses the same processing rules.
We have several implementations.
We may split the python code to a seperate repo.
2 new implementations on in typescript and one in java.
The new java implementation by Taka from Authlete has an excellent
readme
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-sessb-oauth-21-and-browser-apps-bcp
Aaron: best practice for oauth apps running in browser (typically JS)
complimentary version of "native apps" spec
There is a new section on storing tokens in the browser, such as using
local storage, keeping the tokens away from the browser using a backend
component.
"why not to use cookies to store tokens"
Reference to sender constrained tokens and DPoP
There is a new section that is about aquiring tokens instead of building
an app.
Lots of editorial updates.
A note about implicit flow, and support for CORs
Lots of discussion about service worker pattern.
We have described the limitations of service workers for managing OAuth
flows.
new pattern: BFF store access tokens, but store them as http-only
cookies
storage isolation: TLDR there is no best way to store tokens in
browsers, XSS attacks are a thing, so using a backend just moves the
problem elsewhere... service worker is a decent option, but then there
is no persistent API, and indexdb is shared.
should we document the gap in browser tech, where we wish there was a
better solution
should we ask for a better api to store tokens?
Torsten: i think you have your best practice already in mind, "just use
the backend"
Aaron: should we identify
Orie: this is a gap that we feel a lot as webapp developers; 100% the WG
should reach out and engage other communities
Mike j: is browser storage landscape part of what's changing? does it
differ?
Aaron: afaik, no pending changes, relatively consistent
Kristina: The W3C FedCM is working on putting browser in flows, and
perhaps already has ideas about storing tokens
Aaron: would be great to reach out
David: some browser sandboxes are more strict for isolation
it would be a very big ask.
Tobias: this would be a good ask of the community, what woul dbe the
properties of a secure storage?
Should we gather deeper requirements before asking?
Aaron: it would be nice if the service worker had a permanent storage
location that was isolated to the service worker.
This would address token theft, but not token use, as it says in the
draft.
The other option would be DpoP with a hardware backed key, which would
require coordination with OS vendors.
That is a much bigger project.
Not posible to capture as a BCP, since it requires future work.
The edge is going up to but not covering hardware backed keys.
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-sessb-oauth-21-and-browser-apps-bcp
Aaron: Client ID definition, is now meant to allow for clients to bring
their own ID.
The text around verifying the identity of the resource owner.... its
also been awkard, and now it refers to authenticating the user.
Changes in the context of the security BCP have been back ported.
Lots of editorial.
The grant types are now main sections, and they define parameters, and
they all extend from the core token type.
scope parameter is defined by specific grant types.
Aaron: explicit resource owner authentiation, the idea is if a client is
not authenticated, there is text that says the AS SHOULD involve the
resource owner... vittorio asked if they means prompt for credentials...
what does "involve" mean?
Does this apply to public or confidential clients?
Justin: This is really tricky to specify, because there are a lot of
systems today, where there is no strong auth event, and there is instead
a "risk endgine", i beleive this text comes from OAuth 1 world, where is
was expected to be a full user authetnication (logout and login)
Stating this is requirments langauge is difficult.
We know the resource owner is there, and what do we want to avoid:
We want to avoid the case of an attacker quietly creating a session on
someones behalf.
Torsten: I think I wrote that text, the intention was to add another
check in cases where you cannot auth the client. it was intended for
public clients, and to get a confirmation from the user, i think it is
inline with existing methods and OAuth 2 philosophy.
Another check for public clients to prevent impersonation.
George: piling on, consent is what I have seen used for this scenario.
Aaron: The question is do you want to re-auth the user? or... We should
make it clear we don't need to ask for a password again, but confirm the
AS is still happy with their session.
Vittorio: It sounds like we want to provice extra opportunity to the
user, but the user is easy to fool... I don't think we can do much
more... perhapse we should use the word consent instead....
Aaron: sounds like we should ask the user for consent.
Aaron: similar to the last issue... The prompt = none flow / another
authorization request.
Maybe the SHOULD is fine in security considerations, maybe we don't need
more clarity here.
Torsten: It is in client impersonation section, it is meant to improve
security in public clients.
Aaron: public clients still might want prompt none, silent flow
Torsten: But thats a contradiction, we don't know who you are talking
to.
Vittorio: using the iframe is completely mainstream; "should" covers us,
but a lot of people look at our specs as guidance
We should clairfy common practice for access tokens without bugging the
user.
Mike Jones: this is common practice and it serves to support user
experience.
Regardng torsten's comment, you are talking to the same party on the
channel you were already talking too.
Aaron: but that is the issue, the silent refresh gives the attacker the
token, even if the burden for the attacker is high.
Torsten: you don't know if the party asking for a refresh token is the
original party.
We should spell out that the attacker may get a token.
Mike Jones: you are already processing content on this channel.
Aaron: one example is dns poisoning; silent refresh could point to
something else
vittorio: couldn't you just use the url to ask for a new token anyway?
good to call out, but just saying 'should not' scares people too much
Torsten: There is a combination of mesaures that must be in place, the
redirect and uri checking, leaking of codes should be prevented to
outside parties, if we connect those 2 pieces I would be fine.
Filip Skokan: Adding on to what Torsten agreed to, some context would be
good, beyond redirect uri, we should do what we do today to make sure we
respond to the same party, is validating the origin that we post message
the response to... we already do this.
Aaron: native apps BCP, most of it applies to mobile phone OS, and not
desktop apps.
Many desktop apps do not follow mobile app guidance.
The way to capture the current state is leaving the desktop world more
open... and take native apps recommendation and make sure it refers to
mobile os.
vittorio: good rec, but we can do better.
Some things work in mobile based on isloation
Lets not blindly ask people do to the same things we do on mobile,
because the benefits are not there and the experience is not good.
Aaron: See the section on grant types, client id is in there but we
should make it optional.
each grant type will say whther or not it's required
https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-clienttrust-management-00
Torsten: Kristina, Tobias and I are presenting an extension for robost
mechanisms for client metadata.
To give context, we are working on a set of protocols called open id for
verifiable credentials.
The fundamental problem which we discussed at IETF 115.
There are lots of parties, issuers and verifiers.
Normally this would mean a wallet would need to register with lots of
issuers and verifiers would need to register with lots of wallets.
An AS should be able to use external client ids (outside party id)...
not necessarily trusted.
client id and client metadata can be externally managed, but... there is
not just one way to go this.
We wrote a list of mechanisms we have discovered in the wild, inclusing
dynamic client registration, x509, DIDs, TRAIN, etc..
We have seen ecosystems use a mechanism, such as in open banking dynamic
client registration.
There are also proprietary mechanisms.
A wallet miht need to be connected to multiple ecosystems, for example
EU EIDAs might need x509, but the wallet might need to connect to
multiple ecosystems.
The wallet should be able to determine from the request context, what
mechanism would be used.
The mechanism impacts in the request must / should / must not be signed.
For example there is trust chain in OIDC for passing additional data.
This could be complex to implement, we decided ot add a new request
parameter.
to dinclude to the AS which mehtod a client wants to use.
we call it a client id scheme, it determins the behavior of the wallet,
and additional parameters, including conveying client meta data that
might be attested or self asserted.
Some of this is built into OIDC for Verifiable Presentations.
List of mechanisms:
Still considering:
Kristina: VC requires profiles; ISO provides one profile for mdocs,
including x509 mechanism (very specific to ISO)
not ment to be exclusive list here, meant to have extension points
Torsten: on the left, authorization request using redirect_uri and
client_id as the same value, with additional self asserted client meta
data.
on the right, you see a request that uses OIDC federation, using
entity_id using well known location and api endpoints to validate a
trust chain, andy redirect_uri is allowed as long as it comes from the
apis
These changes have simplified the specificaiton text.
Tobias: client_ids that are not managed or signed by the AS, we want to
support wallets and credential exchange, but are there more use cases we
should be aware of, is this generally useful for OA
in the past, some customers interpreted structure of client id is a
problem, like AS depending on internal schema
things break when AS changes its internal schema
There are risks generalizing structured client ids, there is some risk
that this may impact future clients.
Torsten: The wallet in this use case acts as an AS. The client id may
not have structure, it is up to the method.
We have already crossed the point where the AS manages client ids, we
have gone further to indicate how the outside party is managing these
identifiers.
Pieter: Interesting in the context of workload identity, its nice to now
have the AS manage these identifiers... Evan you might want to say
something.
Aaron: I agree with most of what you have, but in which situations are
paramters required? How do we know when a parameter is needed, and how
to we ensure people don't end up with stuff they don't actually need.
Tobias: we don't want to encourage people to sniff the client id
Kristina: the multihoming nature of the wallet, is emerging as a
pattern, in some cases we may need to use DIDs, in others we must use
x509... and it can lead to sniffing... and it is not great.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture
Nat: PoP architecture document
started back in 2014. pretty well-written
assumed it was completed, but author of an academic paper couldn't find
the draft
The draft is not present in OAuth becuase it was marked dead.
was almost ready -- passed IESG review
still believe it has useful information; we talk about
sender-constrained a lot these days
do we have an appetite to have it cross the goal line? (so it can be
referenced)
Hannes: Back then, we worked on a lot of documents, and this was the
overview document.
it looked like the authors lost interest and steam on it... it will
require updates.
Justin: I forgot I co-authored this.
At the time, we had plans to move OAuth2 to move beyond proof of
posesssion and the there were lots of other ideas (HTTP Signatures)
I think it makes sense to relate these concepts.
Perhapse we can references mTLS and DPoP drafts.
Roman: I heard procedural... this went to IETF last call... this
basically would be a new document, if we pick it up.
Richard: My impression is that proof of posession is the future of this
community, we are headed towards a world where this is important, and it
makes sense to revive the draft.
Joseph S: I think this would be useful, it needs updates, I would be
happy to review.
Kristina: Where would this draft be referenced from? I would Hneed time
to review.
Torsten: lets first learn more of the context.
Nat: only within IETF, but a lot of people seem to be talking about
sender0constrained or key-constrained things, with different vocabulary
Torsten: struggling to understand how pop architecture fits into that
picture given we have dpop and mtls
nat: more than just terminology; list of potential threats with each
type of thing
Roman: we need to finish security BCP, lets not hold that up.
Evan: I am presenting today with Pieter K.
I'm new here.
We have been discussing workload identity and OAuth.
The goal today is to give context on SPIFFE, and use cases.
make it clear how they work together
see how/if they can converge
SPIFFE is a set of specs
SPIRE is the only standadalone one.
SPIFFE solves the bottom turtle problem, workloads come and go all the
time, and they need to be able to establish their idenitity.
short lived documents and key rotation from the root all the way down.
there is no authorization, we look towards it, by establishing a
foundation and letting poeple bring their own framework.
We like to define using profile son top of existing documents.
2 primary ones today are x509 and JWT.
we provide trust bundles as well.
SPIFFE have a lot of overlap with OAuth (but they aren't the same).
SPIFFE to boostrap an OAuth client.
SPIRE is when a workfload works with a server to provide remote
attestion to establish an identity.
how do we do workloads in different domains?
choose your own adventure today, very undefined
registration in oauth, we have hosts where they have an identity
already, how can we add workloads to this?
SPIFFE keys rotate very quickly, so validators need to be aware of key
rotations.
This blends with user identity, and policy issues
for example, a payment service which only wants to move money, if the
owner of the account has issued the request, and the request has
transited the fraud detection service.
SPIFFE required aud to be set, but it is not super strong.
We are interested in token binding to the request.
It is important for SPIFFE to avoid expensive network calls... because
of perf and availability issues, we want local operations.
not as sure how well this fits here
As attestion processes occur, they emit useful signals.
How can we consume this at policy decision point?
useful for implementing ABAC.
SPIFFE has federation, but we support x509 and JWT.
How to discover the JWKs endpoint?
How do you authenticate the endpoint?
Once that is exchanged everything is good, but it is hard to
encapsulate.
SPIRE is good.
Use Case *
Have any use cases?
Pieter: Next steps, we want to document connection points to OAuth... we
want to show how OAuth can bridge to SPIFFE.
Should we create a BCP?
We are seeking feedback on this.
Vittorio: Thanks, like your scenarios.
Is there a layering mismatch?
OAuth does not do identity but can be used to carry identity.
I would expect SPIFFE side to say how they use OAuth, not the other way
round.
Evan: Not sure how to connect to OAuth because of key rotation; had
engaged in MTLS discussion
Joe s: would be useful to define, don't know exactly where
Lots of use cases, maybe they don't all fit in this group.
Evan: could be in our community, most important thing is input and
collaboration
Note takers: Hannes Tschofenig, Joseph Heenan
Roman will talk to the IESG about the extra side meeting time that was
cancelled and how to resolve this problem in the future.
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
Rifaat: Purpose: audit trail, real time isplay of info, eval & auth
Use case includes embedding tokens from other issuers, e.g. STIR
diverted calls, id tokens from other parties to aggregate different
claims
Tokens to be embedded are sent to token endpoint in new endpoint,
response with new token is returned directly or be value.
Authors are asking for a call for adoption.
Atul: What's an example with more than one token?
Rifaat: Typical use cases are one token, but didn't want to rule out
multiple. Guisseppe has one use case with multiple.
Vittorio: Token exchange is misunderstood. Concerned we're doubling
down. No guarantee AS at end of chain understands claims from other
parties. OpenID Connect as claim aggregation.
Nat: id_token has facility to include other tokens.
Mike: This is aggregated & distributed claims in OpenID Connect core.
Rifaat: I will look into this.
Aaron: Concerns if access tokens are being embedded into other tokens.
Not familiar with STIR so not sure if that token has the properties of
an access token or not.
Atul: Is it okay to embed an access token into a different token for an
audit trail?
Rifaat: There are some concerns if it's a simple bearer token.
Atul: Should check that sending party has authority to delegate token.
Dave Robin: Alarms bells with sending access tokens to other tokens.
Consider removing signature or have security considerations.
Rifaat: Absolutely
Hannes: Should bring this to the mail list and answer some of the
questions.
https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/
Pieter goes through his slides motivating the attack.
Main changes to the draft: Distinguish protocol patterns. Added further
examples and more exploits. Mitigation limitations added.
Next steps: Work in secure ranging and proximity, OpenID for Verifiable
Presentations over BLE
Open issues in the Github directory. Trying to coin phrases for the
different attacks.
Formal analysis of the cross-device flow is ongoing at Stuttgart
Yaron: It is great to see people from academia to do a formal analysis.
I would also like to see people who analysis the usability. I would also
like to see the case covered where multiple requests are sent and the
user has to decide. It will typically make the wrong decision.
Pieter: Do you have some contacts you could introduce to us?
Yaron: I will see what I can do.
Presents the results of discussions among a group of people, as a
preparation for this meeting.
Different protocol flows discussed to address the use cases. Utilizes
token exchange as a building block.
Vittorio: The problem is not the wire-presentation but rather what needs
to go into the token. It is not just a token exchange. Scalability
should also be considered. Some of the information you put into the
token is actually an environment variable.
Pieter: yes, definitely issues around latency / round trips with
microservices etc
Hannes: Many of problems have been around for 20 years, lessons can be
learn from prior attempts to solve. Would call it a semantic mismatch.
Work by Aaron, Pieter and George. Aaron presenting.
OAuth for Native Mobile Apps. Not considering desktop for now.
Current solutions are great for third party for security etc.
Not good for first-party apps. Apps authors are unhappy with forcing
users through browser. People are finding solutions to avoid RFC8252
(see slides) but create new problems.
Hope is to come up with a first-party solution that uses native
components.
Rohan: Doing this work and standardizing it is important. This is just a
pain for us (Wire). [Rohan explains his scenario.]
Joseph: Definitely should work on this and clearly define what a
first-party app is. Also look at app-to-app communication.
Vittorio: We already have this today. You leave the biggest part
undefined. We leave all the interaction with the AS undefined (as
Microsoft does). I would like to see proposals to evaluate them since
the devil is in the details. FIDO might be a better place to do this
work.
Aaron: We do have a couple of drafts and I didn't want to burden this
discussion with this. (Those define the wire protocols)
Justin: Vittorio's point needs to be seriously considered. There is
merit in defining the protocol but it worries me that we will see
proposals for sending passwords around.
Rohan: We used HTML forms but we want the semantics defined.
Justin: That's the reality of HTML. I don't know what we should do.
https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata
There is some overlap with the next item. Both drafts enable RSs to
identify ASs for a client to use.
Resurrected old draft from 2016.
John: In early days we indicated what AS is required by the RS along
with scopes. This, however, raised concerns with security. This would be
useful but we have to put in thoughts about security implications.
Nat: Some of you may remember the OAuth Meta Draft
(https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-meta) from
2012, which was developed till 2017. The push-back was bearer token use
but now we have phishing-resistent credentials and it might be useful to
bring it back.
Joseph: Agree with John, though this needs to go further than just
security considerations. We need to make sure the flow breaks if user is
sent to an authorisation server that doesn't know about this resource
server, even if they don't know about this new proposed draft.
Justin: This is a great idea that has sharp edges. This is deployed in
UMA-based systems for a long time. GNAP does have a similar feature.
There are some pretty big security considerations. There are
well-documented attacks where fake discovery documents are used. There
is also a huge privacy consideration here. We are going to a more
distributed system and there are a lot of sharp edges. I don't think it
is a bad idea but it is a dangerous tool.
https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/
Aaron wanted to continue the presentation on the next draft. He provides
a number of examples (calendar apps, email apps) where RSs and ASs have
no prior relationships. Not all use cases need this. The user
brings/creates this relationship.
Aaron believes that the non-phishable credentials are ready for
deployment now.
Aaron suggests to adopt draft-jones-oauth-resource-metadata.
Justin: I love this space, which is why I worked on the dynamic client
registration spec. It is still a difficult space and I would be in favor
of combing both approaches because there are use cases where one or the
other solution does not fit.
Kristina: In the OpenID for Verifiable Presentations spec uses an
alternative approach (see spec)
Joseph: You indicate that this is a user-driven flow. Putting this
responsibility into the user is difficult. Using the resource indicator
is good.
Aaron: The user is already responsible today to configure a mail client.
We are starting with this assumption.
Joseph: Agree with this but in other places we go a long way to avoid
putting responsibilities to the users.
Aaron: The problem scope is that we are in that world already.
Tobias: The .well-known approach is probably more inline with today's
OAuth approaches. I see use in both mechanisms as well.
Aaron: There is also a relationship with the step-up authentication
draft.
Vittorio: For step-up authentication draft we explicitly rejected the
functionality of discovery. For the overlap we should talk.
Mike: Should we try to produce the combined draft?
That seems to be the way forward.
https://datatracker.ietf.org/doc/draft-vattaparambil-oauth-poa-grant-type/
Sreelakshmi starts the presentation.
Nat: OAuth uses a three party model. In OpenID Connect we have a 4 party
model with CIBA. CIBA =
https://openid.net/2021/09/01/openid-connect-client-initiated-backchannel-authentication-ciba-core-is-now-a-final-specification/
Rifaat: Did you post a mail to the OAuth list?
Sreelakshmi: No, I haven't.
Olov: We have collected all the comments from the London meeting.
We also do multi-level delegation by doing PoA inside PoA.
Aaron: I wonder whether we could do the interim meetings again. I
thought that those were very productive.
Rifaat: Send us topics.