Note takers: Kaliya, Hannes, Joe, Brent
Rifaat thanks Roman for allocating three slots and Roman explains that
this is an experiment.
Pay attention to the Notwell :)
If you are remote please keep audio and video off.
RFC 9268 was published a few months ago.
Congratulation to Thorsten, Brian and Justin.
Hannes: Reviewing the document here were some changes sinc last review.
It is a very solid document.
IAB identity program some have been talking to them. They will be
creating a program about identity. Chris will be talking about it at IAB
open meeting. Cullen and I talking about it at SAG meeting at 3:30.
Leif: The overlap with GNAP on Friday is very bad. I am one of the few
people participating in the wallet effort of the EU.
Roman: I take this on me. I told the secretariat to explore all options
for finding a third slot.
Brian goes through his presentation and presents the changes made to the
document.
Rohan: What are the items called? the values in the _sd array and the
other elements?
Brian: the list of digest values is included in the _sd array and it
points to disclosures
Rohan: In terms of the disclosure, it potentially reveals private
information.
Brian: What I showed was the disclosure of the individual array. You
could disclose the entire array and thereby mask the true number of
included element. This would obscure what is in there.
Mike: Length of the array disclosure can be an issue. Adding some
information about adding decoy elements. Would be helpful to have some
privacy guidance.
Brian:
Not sure how to give specific guidance. Abitlity to add decoys in
Nationalities - might always include 10 nationalities rather then true
number. Open to suggestions about how to do it generally
Dick: Nationality syntax - looks terrible (like a hack) I will write up
some ways to do this. You could model data differently. Deployers want
to model things as an aray. Could be modeled as object and use other
syntax. Confused about how it works. Here is data about people and how
does that get into being an object. Build up about how all this stuff
works. Anyone coming in new - super hard to parse what is happening.
Short Update - no open issues.
Aaron believes the document is ready for working group last call.
Chairs will issue a working group last call (after the IETF meeting).
Aaron is asking for help for issue #118 regarding string manipulations
on application/x-www-form-urlencoded
Hannes: Use this IETF meeting to talk to the HTTP community to find a
reviewer. Maybe we could start working group last call way before IETF
meeting
Rifaat: do you have a list of things/examples
Any time ther eis example request and response bodies. Make sure syntax
of headers is up to date. Content type Application JSON - specified
character set - because it is specified already. Someone who is better
attuned to working with it all the time spots very quickly.
Mike Jones: Get Mike Nottingham's eyes on it - as we were doing IANA
registration suggested some good things.
He is a busy guy but nice and will help if you can get his eyes on it.
Hannes - we reach out to Roman, they have a process for this type of
thing he can work on it.
Roman: we can request an early IANA review
Dmitry: Slide "planed changes"
The document says it is expected that additional response modes will be
defined by __. There seems to be a conflict.
Aaron: Prevent bad things from happening because browser should not be
making a JSON request to end point browser should be redirected. ?
Aaron: OpenID should not be in conflict.
Mike: If you could write to the list about what the conflict is that
would be great.
Brian: I remember removing the redirect_uri.
Aaron: The conclusion was to remove it and if it is the only breaking
change then we put it back. But there are also other changes and so it
got removed.
Brian: I was on the fence on this one and I recall that we talked about
it.
"Now with Extra Stuff" :)
For use cases where the client does not know the resource server.
Document enables client to dynamically learn this information (at
configuration time).
Question about return a different resource identifier hostname than the
one to which the request was made.
John: I don't see a prolem. We didn't do resource metadata because it is
a great fishing opportunity - could create fishing place that "looked
like google" for a legitimate client. Until everyone uses Passkey I see
security problems.
Mike: Short answer is that often case you can dynamically establish
connections they do have a white-list - certain Okta servers are fine.
Aaron: Go back to slide 3
This screenshot is the current use experience in many applications. This
is also a fishing vector.
I don't think it is worse what Mike proposes. Reason: there are more
opportunity that something is wrong and we have technology to solve the
problem (WebAuthN and Passkey) to solve the fishing problem and to make
it more obvious that there is a problem whereas the current experience
is worse. I think it is an improvement. As we get more deployment of
fishing resistant technology it will get even better.
Neil Jenkins: I agree it is an improvment. We have way people put in
their real e-mail address to get to . With Bearer response to we need
intermediate well known. Wasn't clear about those intermediate steps.
Mike: THis is what Aaron draft did. It did not provide you other
meta-data about the resource, such as protocol elements support /
not-supported. This gives the resource to, in the future, only hand out
DPOP tokens. There are lots of things you can do with a general
meta-data service. There is value in making this extensible (if you
don't know the AS and the RS in advance).
Neil Jenkins:
one final point could make it work with same domain would be easier if
you could make it a different one.
Mike: who would like us to help write security considerations. If I
don't get any volunteers I will go to santiego and talk to John.
Tobias: In situations where the client can provide information about
whether an authorization server has been contact before.
Mike: Thank you.
Next slide (13). Long history with this draft dating back to 2016.
What make this current again - decided wanted data structures and wanted
to use them. Decided to combine forces.
Mike: would like additional reviews. Stuff added strictly additive.
Following reviews would like to ask for working group adoption.
Leif: has some aplicability no consensus of use of federation. Will get
used in large scale pilots in helping organize some of this activity. Is
appropriate.
Dick: Echoing Leif - lots of use. Go back to SD-JWT - I was a little
harsh before. I think it is amazing cool technology - I will read it. It
needs more help.
Rifaat: Are there volunteers to reviewers? Leif, and Pieter
Brian: I did do a quick review of if - I struggled with is the resource
metadata driven by client? I continue to be worried about the future if
it gets adopted and worked on. Path constructs?
Mike: Arm wrestled with Mark Nottingham.
Brian: in this contstruct challenge returns resource. Could we return
metadata and avoid .well-known construction?
Aaron: I like that idea. Bridge two suggest path be ".well-known" but
not make it a requirement. Then suggest that a good place is to put it
in resource
Mike: We could return a URL to the meta-data document, as suggested at
the last IETF meeting. I would like to get the document adopted and then
to discuss it in the group what the right approach is.
Not first to have this idea - it is not a bad idea.
Orie: I agree with the comments. I would like to understand the history
of WWW-Authenticate.
Aaron: This was part of the two different drafts that lead to this work.
I had worked on a path that didn't work on resource metadata at all this
is the combination of the two.
George Fletcher (on the chat): We could return two Uris in the
WWW-Authenticate one for resource metadata and one for the associated
AS. Though there some cases where the AS may change based on the
requester.
Anatomy of attack:
Social Engineering is a big vector.
Now called: "Cross Device consent fishing."
Mitigation: More formal methods - exploring.
Hannes: Use normative language.
Justin: Agree with the use of normative text. You are saying this is
best current practice. Adding normative statements makes a lot of sense.
Roman: AD hat on. I think idea of normative guidance is good. Should,
may, recomended Explain why it is a should or may so folks know.
Pieter: Sounds like good clear guidance.
Back to slides: 16.
Pieter wants to signal that the document is getting closer to WGLC since
there are only a few open issues.
Attestation in Dynamic Client Registration - Hannes Tschofenig (20)
https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/
IETF Rats has formed. Good work to harmonize terminology across
attestation.
Network managemnet protocols.
Adding it to TLS. Using PKIS environment. IoT deviceo onboarding what
will come out of it we will see in a couple of years. Lots of different
organizations and companies have developed attestation properties. CBOR,
X509 or proprietary formats. Details matter.
Why use? Signed document with information about device. slide 3..
Attestation terminology slide:
regular website - relying party.
Evidence gets sent to verifier - uses judgement together with policy.
there is more terminology - so abstrcted.
Map Rats to OAuth dynamic client registraiton.
Noce comes into picture.
Not all use same freshness mechanism. TPM DICE based uses nonces.
What does document do? dynamic client registration. agnostic of client
registration.
Different technologies prefer different implementations. How can OAuth
benifit from ongoing industry trend and collaborate with other working
groups in IETF come up with something harmonized across different
groups.
Collaboration appreciated.
Interest in Running Code.
Aaron: I agree we seem to be reaching a tipping poing of interest in
this area. Last year at OAuth secrutiy workshop - using atestation as
part of registration/dynamic client registration. General interest.
Since then People already deployed stuff in wild.
In thinking through more - leaning towards not overloading dynamic
authentiation or ---_. Instead making it another layer.
Can
Only client ID and only different scenario different client
seems to me pull off as own thing - then re purpose in a bunch of
different things.
Hannes: that type of feedback is what I am looking for. Missed last year
Arron: Slides are there.
Hannes: there are differnet design choices look at pros and cons -
appears to make sense in retrospect.
Orie: hacking way through web AuthN and OAuth should be in this context.
Missed relevenant document that skips this picture.
Strong authentication into
Relevent to atestor or authenticated entity. How to do access tokens
with web authN. Maybe I am using wrong words to describe the request.
Mike: using right words - doesn't exist.
Hannes: He is using the wrong words.
Tobias: I would like to through support behind it more in presentation
on friday. Beyond native app. Workflow identity use-cases as well. Not
just constrained to certain client types. Presentation on Friday might
clear that up. Usage of these attestations on Oauth would love to deploy
with a variety of clients.
Hannes: Orie has modesnt client focus vs. application focus. How do you
get to working configured OAuth client at this point in time. Different
areas we need to look into. We don't know with.
Joseph: That is one of the reasons why separating out into its own
thing.
Hannes: Good thing folks who worked on attestation technologies -
opportunity to get first hadn knowledge.
Pieter: Definately very supportive of this work and conversation and
figuring out how it fits with other proposals. Tobias' proposal. How
does it fit with attestation concepts in workload identities.__ space
SPIFY identity as an attested identity and how it fits?
Hannes: Inspired conversations with workload identities. I don't tell
you but interoperability is defined locally between workloads and
agencies - slmost a programming language API interaction between agents
and servers is agent
instead of proprietary APIs for - could use Standardize mechanism. Align
with what SPIFY does.
Mike: question for joe. want to see improvements to client
authentication.
Joseph: what to run into Private Key JWT authentication one of the only
way to do client authentication without using TLS. Doesn't have Nonce
(freshness problem) just solving self signed JWT. That is the kind of
thing I would like to see. Not sure how it relates to what Orie said.
Client auth seesm like on outside of authentication. Makes a lot of
sense. Effort in lance. Ability to indicate if private key is exposed in
hardware. Interesting thing to know. Go beyond platform atestation. More
powerful. Ramp up level of security.
Hannes: Call in August to talk about this more.
Roman: Do an interim meeting
Chairs: Any other business?
See you tomorrow.
Rifaat wishes Vittorio speedy recovery.
Rifaat reminds the group to look at the IAB identity program.
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
Dick goes through his slides.
Atul: Concern about the possesser using the embedded token
Dick: I'm pulling up at a more meta discussion. The token type can say
what you can do with it. Access token for example. 2b - you can go get
specific about a particular type of token.
Atul: THere are claims within the token that talk about how the token be
used. There is a lot trust placed in the recipient of the to not to
represent themselves falsely.
Dick: Right I think that is an important detail to talk about what I am
working to describe is at a higher level about how do we do these
things. I think per my description will be specified by the type.
Per your question it is a security secure - people could abuse it it is
an architecural decisions about if I am embeding token or not.
Leif: that is an architectural decision, how do I find my token and
ensure that nobody in the middle throws it away
Dick: That could be.
Leif: there is a reason to have a bag of tokens, I try to find the stuff
that is relavent to me. That is the only concerns there are few or no
other processing rules.
Dick:This is why I'm bringing it up in the working group. there could be
things. You have rephrased what I am asking. Is there generic things or
not.
Leif:
Dick: I gave my choices out of order. 2a 2b. 1 we don't even spec the
container
Leif: there is one more generic considerations, make sure that someone
in the middile does not remove the embedded token.
Dick:you could take anything out. You are supposed to ignore things you
don't understand.
Dick: pros to have some mechanisms. Libraries have some understanding of
what is there process embedded token.
Hannes: Use some form of content type. You have the type or media type
which gives enough information to parse the token. Is it overboard to
include the type as a URL.
Dick: The point of the session here is to get the feedback on the pros
and cons of three different approaches. Is there even value in specing a
container. If option 1 is good enough people can define their own high
level URI either standardize it or look at it.
Mike: I think option 1 is goo enough. If you go with option 2 the
ability of generic processeors is OK but just know its a jwt doesn't
tell you the processing rules. We could reuse type values from the token
exchange specification.
Yaron: Regardless of the solution. We pick here it is important to say
we are conflating name and type. Name is what the application thinks it
is. 4 tokens different semantics. Type may be standardized and denotes
what a standard library does with this token. One field and call it type
and it is really two different things.
One is what it looks like from application point of view. "My third
siblying is a person"
but a type may be a type of well known tokens.
You are still using the word type to bundle things together.
Dick: slightly differnet meanings of what the word type means.
Yaron: I prefer the URI option since it offers more flexiblity.
Dick: I'm clear making up things to put in the string.
Yaron: The benefit of having a URI is that you are preventing the name
collision.
Dick: If you go to 1. doesn't have a wrapper.
Yaron: I don't have a preference.
Orie: Sorry if it makes more complicated. Isn't this similiar to the
distributed and aggregate claims in OpenID Connect. Aren't they sort of
a version of this.
Rifaat: we did look into that, this is completely different.
Dick: that is a specific type of claim with a specific type of meaning.
OpenID1 these are claims inside of an ID token - much more specific.
Leif: Spec it out. Have a draft that defines how to use this. This helps
people to understand. It might help the question in form of a draft.
Dick: Answer the question in the draft. with some guidance about how to
do it. Text around the tool - someone might get this and do things with
it.
Rifaat: Normative text about how to do something
Dick: like that with high level claims.
Brian: isn't option 1 what STIR (with Passport) have already done? the
didn't name space it with the URI. It is already happening.
Dick: the fact it is a URI namespace. They have taken approach 1
Dick: there are a number of concrete name spaces we could specify - +
general compentary.
Brian: You are specifying a wire protocol to request and receive?
Dick/Riffat: Yes, since it is related.
Brian: Extend token request. Seems like scope of what you are talking
about it is token formatting question. Once you have format need to
describe how it got into there.
Dick: should this be different document on interactions?
Rifaat: are you saying these should be completely differnet documents.
Brina: looking at stir and how they do it they just put in ---
Hannes: are you saying it should be a seprarte document.
Brian: probably, but I don't know those documents need to exist
Dick: Important point. more then syntax of an embeded token how to get
it inthere like what STIR did. How should you embed tokens.
Dick: Person implementing two things. Read two things.
Brian: the application already has a way to embed the tokens and does
not not to read document about embedding tokens. I think the document is
overloading the concerns.
dick: anyone implementing needs to do both. Here is protocol part and
token part all in one document.
DIck: brought up useful stuff that is protocol related not just how to
embed a token
Rifaat: if there is something to be fixed there we will fix it.
Pieter: so whether this is a BCP or standards document, have clear
guidance is super useful. If not people will solve it on their one and
do something bad or dnagerous. Hving the guidance is good and I support
it.
Dick: Do you have a view on 1 or 2?
Pieter: I don't have a strong preference. The more you can constrain it
the better. The more flexibility, the more you will have to specify
later, what is the minimum set of things you want to specify now.
Dave Robin:
If I have two tokens of same time- need a name to differentiate. Clearly
need a name.
Dick: What could be embedded, could be two tokens from different
"countries" indicating your citizenship.
Dave: needs to be usage identifier
Dick: need
Some disagreement about what a type is.
Dave: Meta Question: Why are we focused on putting in guidance about
tokens. Just custom claim and custom data. What periods and repeate ICS
- it is a thing. Why are we concerned about embedding token or something
else.
Dick: That is the question I am asking is ther value in having
containers.
Dave: 2A and 2B are giving A name to the cusotm content.
Dick: Is that valuable.
That is the question.
If i don't understand tehse tokens anyways. BTW this things is a token
just a wrapper.
Leif: This is a good argument for 1. You need to provide guidance for
implementers if you are not sure how to do this.
Dick: Is anyone thinking that providing guidance is a bad idea?
Brian: I don't think it is a bad idea but if it is bad guidance...then
we need to be careful about what we do.
Dick: So brian I am going to interpret that as a review volunteer, thank
you.
Brian: I would remove the protocol parts. Option 1 would be the
preferred. The term "type" is terribly overloaded. I don't think it will
work out well in practice to define a generic layer.
Dick: Great feedback. Taking feedback. There is strong preference for
having a docuemnt with approach 1 instead of 2(a) or (b).
Dick: next slide. Not ready for adoption. consensus there this problem
should be solved and we should have a document. Authors will re-work the
document for approach 1. We have gotten great feedback.
https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/
Shares slides.
Slide 6 - change from short lived OAuth token to any type of short lived
JWT of any type.
Looks like a JWT
Atul: Subject ID are no longer in the shared signals draft
Leif: Sec tokens.
Subject Identifiers:
https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/
George: You could stick stuff in there like device identifier. Can also
have authorization specific data. Questions at Leaf node or micro
services. Do you need to encrypt some claims? etc.
Side benefit maybe all of your systems do this well. Seen many a back
end where services go through. Having something like a transaction ID
that everyone call log gives you some of that flow that your "cyber
security people" will be very happy about.
Justin: Is the AZC section supposed to be namespaced, typed?
George: I think that there is some set of claims that is generic and a
lot of extensibility. Should transaction context information, device
fingerprint be separated authorization or transaction details. You could
pass in a RAR structure.
Tobias: Is External token is tranlated to internal token in gateway?
George: yes this at least initialy is internal to one trust domain.
Could do it at gateay - could be inbound mail - actual mail application
that starts it - as close to edges as possible.
Tobias: At the boundary of the trust domain
George: yes
Leif: Wondering how close this is to Sec Tokens. Looking at the
structure you can probably look at Sec Token format. This is an
application of the security event token. Set of events that has
extensability for context.
George: ok.
Atul: I think that's a great suggestion and we should have thought about
this.
Next Slide 8:
this kind of token is short lived. No associated access token that is
shortlived just for life of transaction.
Dick: These tokens are more an authorization token rather than an event.
That was not the intend of sec event. Moving it into sec events would
distort it.
George: That is true. There may be good pieces of sec event that we
could use for this, but not an event itself.
Dick: No disagreement on that. To call it a secrutiy event is an abuse
of what a secruity event is.
George: Not technically a community event in the context of that
comunity event.
Kristina: Are you looking only to standardize the format of the token or
how to get it.
George: There is a protocol element in here.
Kristina: What was the motivation for defining multiple subjects?
George: the subject value itslef is a little bit clear it could be
different in different contexts, so having the multiple names is typed
could be cleaner. The entity is still singular (different names for same
thing)
Kristina: If we go into the path of defining the subject as an object,
then ... ?
Atul: We are not saying that this work should be moved to sec events. We
are only considering using sec events.
Brian: Using sec events as a format is terribly confusing. I would
suggest not doing that. The sub-id is defined in soon-to-be-defined and
this document is just using it. It feels more appropriate to use a
sub-id instead of sec events.
Dick: Part of Sec events.
Brian: in order to understand the context across domains.
George: its is possible that the entity that is starting the rquest may
not have access ot the cononical identifier for a user. This can be
useful for downstream services that need it. Gives a little more
extensibility than just a plain string
Tobias: This use case is not only about the external token being
inappropriate for internal services. It is important to harmonize
different authorization tokens from the outside APIs into one consistent
authorization service internally.
Ability of API gateway to go to the server. So downstream services Some
level of meta authorization service. None of that is in the draft yet.
we have very first bit of a draft. Feedback appreciated.
More questions:
Probably overlap in how these things interact with each other. More
strurctually presented then we have in the past is it another best
practice document.
Justin: I am very much in favor of doing something. Not conflate
internal token like this with chaining and stuff. Looking in more
use-cases, a token is not the right tool. We tend to think with tools
that we have - like tokens.
Transaction token is great. People have been doing this for years.
Like cross domain things. (WIMSE)
https://datatracker.ietf.org/doc/draft-identity-chaining/
Shares slides
Pieter: Do we need to define claims.
Additional profile?
Riffat: anyone have any thoughts at the level of the problem trying to
solve here. Justin seems to be in favor of doing something.
Orie: There is a part of the cross-domain interaction model it overlaps
a bit with the discussions in the SCITT working group on federations. My
transparency service controls my trust domain and your transparency
services controls your. At the same time there is some cross-domain
interaction. I believe there is need for a discussion with the SCITT
folks.
Pieter: Thanks I didn't think about that as an application
Brian: For better or worse I am responsible for the assertion series. I
have envisioned the assertion drafts as a way of cross-domain
interaction and the token exchange being more local. Always has been way
I thought about it. Value of writing down something like this. Some of
the pieces you are building on have problems (sorry for that) but good
to build on.
Rifaat: Does anyone think it is a bad idea to work on this? Nobody
responds.
https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-native-apps/
Focus on mobile apps.
Aaron explains the use of the authorization challenge endpoint. Says
that the new API returns an authorization code.
Brian: This makes a lot of sense.
Dick: Application might implement separation of concerns, underlying
infrastruct may be different.
I think it is a good approach.
Aaron: I agree with that. if you look at the two end points in OAuth
they do two totally different things. 1) process token 2) Errors
We are not changing anything regarding the token endpoint.
Continue with slides 19 explaining why the new endpoint accepts POST
requests and returns HTML.
Aaron: John, can you write a draft about how to use this with FIDO?
John: I would love to tell you how to do it but I don't know it.
Let us step back a bit and talk about the AppAuth (BCP212). It has
come under some attack (referring to the discussion on the IETF mailing
list) and it is an indication that a few people are unhappy. This BCP is
what enables apps (such as TripIt) to go accross various apps to work
(in a federation style). I am not opposed to a new pattern but I want to
avoid that we break applications with it.
Aaron: In an enterprise case I would expect it is never used. A good
half of the draft describes where this should be used. THe authorization
server
John: So I think we may need to if we are going to introduce this new
mechanism we may need to introduce the BCP. William Denis and I wrote
this 5 years ago.
Aaron: it was almost 10 years ago started in 2014
John: Was approved in 2017. Somebody like twitter. Apple shot self on
foot people who updated their secruity can no longer login on android.
Aaron: argument for kicking back to broawer. If Tripit want to log in
enterprise users they would kick back to the web for that.
John: Since you volunteered to update the BCP, we also need to do the
work to include WebAuthN in JWTs (as the client authentication or
providing evidence about the user authentication as part of the backend
interaction). Figuring how and where to do this would be a good thing.
Rifaat: going to drag you guys into a call wtih Val.
George: Using the token endpoint with code another reason to to this is
because you may need to kick out to the web.
Aaron: Makes a lot of sense.
Orie: So the device session (to be renamed) flow. I have seen at least
one api to be designed flow. Transaction identifier and bounce around
loop. Gathering all these pieces to be a proper token.
Aaron: Worth looking at other existing solution.
Tobias: When you say "bounce out to the web" is this a finished flow or
an intermediate flow?
Aaron: The intent was if you ar bouncing out to the web becaue you cant
get an authorization flow from the ___.
Tobias: Extnetions to the authorization qreuqst so if you are startnig
the native app.
Aaron: Pick up extentions got natively.
Justin: To follow on, there is a need to be clear about the inverse of
the error flow is also the case. For example, start with the web flow
and then go back to the native flow. We need to be clear whether this is
an allowed fallback. The other part is with the extension to the
authorization request I am really interested to see how this aligns with
PAR then this could put you into the situation where you never have to
go into the browser.
Aaron: Would recomend building on top or par - output of par would be
externa...(lost it)
This is not a PAR endpoint but it does take all the same parameters a
PAR endpoint takes.
Justin:
That is the point i was raising. Something subsumes par or tists along
side it
Aaron: not make it an extenstion to par - something par can switch off
or this new stuff. felt like more over loading. existing implementation
of par means separate thing. Return value is different.
Give something cary authorization end point will look liek request API.
Yes.
Justin: Not sure it shoudl be an over loading.
Aaron: Good question. Could write up bottom chunk of text examples of
request. rewrite as if it had been a PAR
Justin: Could i extend it to have it be an extension?
Dick: I like the idea that it is a separate endpoint than PAR since it
is returning a separate thing. It seems you are suggesting that you
could send a PAR request.
Aaron: Everythhing you say is the smae as part. might be werid to shove
into PAR endpoint. Response could be
DIck: you could pass all the PAR stuff pluse extenstions into the
endpoint your propose, not sure good idea or not.
Mike: I think I support what Dick said. Write a note about how this is
different from PAR.
Brian:
responding to Justin on how this is different to PAR.
Discussion between Brian, Justin, Dick and Aaron about the details.
The separation from PAR is worthwhile. Whatever we are going to call the
"transacction identifier", currently it is form-encoded content, this is
placing a huge restriction on the API for interacting with clients. Most
developers may want to send JSON data.
Aaron: Is PAR a JSON request?
Brian: No. Form Encoding. There are historical reasons for using form
encoding.
Here is an opportunity for not using form encoding and using JSON. This
better changes.
Aaron: good point, maybe putting it into a header. That is what DPOP
does.
Orie: he said everything I qued to say. I start this flow off a mission
that is complicated - transaction identifier that is retained until I
complete the mission. Assumed a very specific type of JSON that I cared
about.
Hannes: The native apps published end o 2017, There was alot of out
reach, what could we do to get more feedback, some part of the developer
community didn't like it, do we need ot have more outreach? It's weird
that there is a major gap.
Aaron: my understanding. OAuth is JUST FOR THIRD parties. Mobile apps
BCP is also used for this context. no party it is still the right
choice. 3rd party and Enterprise SSO. Can't confince someone to native
login. NOw techincal reasons origin bound MFA. Now people using it for
1st party applications all over. Why trying to open own authorization
server. Started breaking that dosn
Hannes: sounds like a nice story. 1st party use was a topic during htat
time. not something suddenly showed up.
Aaron: wasn't all of a sudden, all of the OAuth documents are written
with context of 3rd party.
George: I would just say its not devleopers its product owners, I want
to design the app look and feel, ets. How do I make it look consistent
(I is PM) the product do care. You cna make security argument, since you
have assurance taling to first party app better user experience is
possible. A mobile app is a tons of signals. It is viable you can do
this context with out user experience at all.
John: some of developers are slightly bitter can't use webview to login
into google because it is not secure. Google Blocked webviews before BCP
even published. Maybe we didn't do enough explaination in documentation
to make it clear enough. Now part of OAuth 2.1. People should be doing
PKCE. Need to look at the grant types. Now mobile devices have passkeys.
Why aren't we doing it. Maybe even simpler direct thing. At some point I
will actually read it. If we optimze for simple case of andriod/apple
phone where they have passkeys on them. Native apps for them to get
passkeys. Still enable enterprise or other applciations using "login
with apple" are breaking out to browser where it is essential. Could be
an important piece of moderinzing it.
Aaron should we ask for adoption?
Rifaat: seems premature, but there is interest in start of problems.
Greetings from chair
Paolo: Thanks for the invite. Want to give a review of the EUDI wallet.
Not so much standards and protocols; more on solicitation process.
Main ambitions are to allow it to be used everywhere by member states of
the EU.
Started with a lot of motivationa and pressure. Strands are working in
parallel. Four different pilot projects. Want to define functional and
non-functional requirements for whole system. Paolo is responsible to
drive group behind technical specifications. The grants will allow
consortia to develop implementations.
Process: Commission, parliament and council working together to develop
regulation. Technical document will explain all of the paerts of the
wallet and the security requirements. On top of technical spec, there
will be implementations to give feedback and implement an open source
wallet. Main componenet is a mobile application, but there are also
elements for issuing and verifying. Plan to have a white-label app for
member states to use.
Wallet implementation should be released next summer.
Architecture and Reference framework: document to represent initial
consensus between member states written by group of delegated experts.
Working to align all of the different ideas. Trying to find a balance of
all the member state needs. Unique identifiers for record matching isn't
common in all member states, so there are significant differences
between member states. This is a moving target. Requirements are
changing. The document is public and we plan to release it regularly (2
releases already available on GitHub). Any feedback is appreciated.
How the wallet regulation works: eIDAS is main one. Implementing acts
define operational aspects, i.e., registration of relying party.
Technical specifications are the rulebooks in ARF to specify rules (as
in the payments work) so that each use case can have independent
requirements. Aspects of the tech stack that can be changed are
described there. Document is describing specific use cases or groups of
use cases.
Hopefully there will be implementations from 1-2 years from now.
Wallet at a glance: trust is the most important component. Not yet
covered in the ARF, will be covered in the next version. Mobile device
is the center. PID is Personal Identification Data. Enables Qualified
and Unqualified Electronic Attestation fo Attributes; qualified means it
is immediately valid cross-border. Un-qualified may not be valid cross
border without specific use case
We have some idea about UX for Electronic Attestation of Attributes. 1st
version of RF to issue QEA (Qualified Electronic Attestation of
Attributes) and EAA (Electronic Attestation of Attributes). The
procedure to roll out the enitity may vary from member state to member
state. Internet oriented (W3C VC) and ISO (mDOC) are included. OID4VP
and SIOP supports remote flow presentation. This is changing still.
Passports and ID cards (digital travel credentials) are examples of
qualified use cases.
Reference Implementation: Supporting mDL and Identification. Plan to
have MVP soon that supports signatures in wallet. Will be open source,
mainly Apache 2 license. The app itself may have a different license
(maybe GPL3). 4 large-scale pilots with different use cases that bring
together different member states and operating parties. Details on
slide.
EUDI walet is for natural person, but also can support legal person.
DC4EU focused on educational credentials / professional qualifications.
The EWC wallet is focused on supporting all the needs of a legal person.
Nobid - less member states, mainly focused on payments (integration with
payments)
Commission is financing 50% of the budget for this large scale pilots.
Use cases: many on slide.
Questions:
Werner: Does this wallet support the use of a social security number in
any form?
Paolo: Yes. The personal identification data can define this. For
privacy there are many different ways to do it, but it will support all
things a member state needs to support public service.
Pawal: ARF mentions PID. Is there a plan to specify claims in this to
allow interoperability between member states?
Paiolo: Yes, that is the plan.
Pawal: but no current work?
Paolo: Not yet.
Ned: Can yopu say more about attested vs unattested attributes? What are
the sematics here? Is an attribute signed by the wallet different?
Paolo: all attributes are collected by authenticated sources and
provided by an issuer, for example the public administration. The values
of the attributes come from there.
Ned: the provenance of the attribute is included with the attribute?
Paolo: yes
https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/
Oliver presents. Director of Identity standards, editor of VC data
model, contributor to ISO mDL spec.
Folks here should know Daniel, he is online. He is here to help answer
questions.
Spec is based on sd-jwt, so recap of those (SD selectable disclosure.
Enables selective disclosure of individual claims). Not verifiable
format.
Recap continued: examples on slide. input claims as plain JSON oibject.
Turns into issuer-signed sd-jwt payload. _sd claim includes selective
disclosure properties. Some claims are not selectively discloseable. Not
on this slide is the actual sd-jwt is compact serialized jwt plus
selective disclosure elements.
Verifiable Credential slide with definition. Paolo gave examples in
EUDI, these are same. Issuer can make an attestation that the properties
aren't tampered with.
Now to the meat: sd-jwt-vc is a profile of sd-jwt specifically for VCs.
OIDC defines additional claims on top of ID tokens (built on JWTs). This
is like that for VCs on sd-JWT. JSON-based payloads. Also defines
validation and processing on top of the sd-jwt rules. Also supports
plain (non-sd) JWTs.
3 party model: Issuer, Holder, Verifier are also in this spec. Flow on
slide. Holder can also include key-binding proof that supports
anti-cloning. Verifier can also get status of vc from status provider.
Mechanism is privacy perserving; Tobias will speak later.
Use cases: on slide. Similar to previous presentation. Focus is on
higher security requirements.
Richard: additional use case: MLS wg have been looking for an end-to-end
secure identity thing, specifically ID in verifiable thing. That
community is loking for somethinglike this.
Oliver: Other technologies: want to keep simplicity of other JSON
formats. public and private claims both supported.
Work status: just started but already referenced. many interested
parties.
Why OAuth? this is based on sd-jwt and jwt which came from here. Uses
JSON-based data model. not based on W3C VC data model. Contributors so
far are already contributing. Seems like the right people are in the
room.
Next steps: on slide. participate in github. Should we call for
adoption?
Ne
Questions:
Ned: not based on W3C VC Data Model, why? Is it broken?
Oliver: the W3C data model is JSON-LD with a lot of optionalities. we
want it to be simple as possible.
We don't want to require people to read hundreds of pages of other
specifications.
Brent: There is currently PR introduce option for other work in other
places to to define information to the core VC data model.
Possibility; discuss.
Orie: I am editor of VC-JOSE-COSE at W3C. JSON supports JSON. JSON-LD
also supports JSON. The pronlem is we can't tell what kind of JSON is
supported. MEdia types help here. I think there is compatibility here
with or without mapping. I would be cautious of defining mapping here.
The sd-jwt spec has a structured suffix media type request. JWT-BCP says
no token confusion. We could leverage that to distiguish between JSON
and JSON-LD. It may bepossible to lean into the token confusion in a
good way. MEdia types and token confusion specific to VCs. there isn't
consensus on how to distinguish them. what is the desing goal, do we
distinguish or not
Richard: My opinion. the VC Data MOdel is fine philosophically, but
there is nothing implementable. This doc is concrete and easy to
implement.
Kristina: nothing to add
Dick: I support this work. good presentation. nice to understand.
Jonathan: I'm in support. we have requirements for FIPS crypto and some
of the other SD schemes don't allow that, good way forward
Torsten on queue. just experimenting how to raise my hand I am
supportive.
Chairs call for hum.
big hum in support, no hums against. Will take it officially to mailing
list for adoption.
https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/
Tobias presenting. Co-editors are online. Paul from BSI in Germany
introduces self - he focuses on high assurance/security use cases.
Christian from Germany, working for years on digital identities in
Europe.
JWT and CWT representation of status list.
Problem: on slide. after issuance, issuer can indicate if VC is still
valid
key requirements: on slide. Some specs don't scale. How to allow
subjects, holders, and verifiers some privacy. Want to disrupt issuer
tracking via herd privacy. work with common formats JOSE/COSE, support
caching.
Porposed Solution: on slide. represented in binary in CWT.
otherwise base64 in JWT
Referenced JWT: Thing that has a status that is being shared. Verifier
can go to status list to find referenced JWT.
Example: on slide. Issuer side resource. Status list itself is signed so
it can be distributed independent of issuer. Looks like standard JWT.
status_list is unique claim. bits is number of statuses indicated in
list. extensibility point in number of possible statuses. So far single
registered namespace. 0 and 1 are defined, but others can be registered.
Example: on slide. collect status, deflate value, check index.
Use cases: focal use cases are around VCs. long-lived tokens that the
issuer may want to show status of. can be used with any of them.
why not other approaches: on slide. ZKPs provide better privacy but are
more complex and don't scale. X.509 Certificate Revocation doesn't scale
well
Leif: Why not other approaches - OCSP stapling should also be included
(and int he doc)
Justuin: Oh, you've reinvented things, what's new. Need to read it to
see differences. We stand a risk of reinventing the same problems even
if we're slicing it differently. Other part I'm concerned about - with
that status array. What if it's all ones? What if they're all revoked?
Do I need to keep that around forever? Once it's full we set up a new
one?
Tobias: Yes
Justin: so it is a CRL. with different scalability problems. There's
been other work using lboom filters and the like. There are alternate
data structures for carrying this information. we need to understand
what else folks have used to tackle this.
Orie: I'm surprised to not see the status list from W3C here. that one
follows the exact same approach. Why not use it. On the compression
side. they looked at many different schemes. Is gzip the best one, do we
want agility.
Tobias: still looking at compression, so far gzip is best. StatusList
2021 from W3C doesn't support CWT and JWT. simple design perspective.
Leif: I support some aglorithmic agility for actual bits in data set.
Tobias: we have an issue to discuss that
Leif: I think this is pretty good. how sparse can it be, what is the
scaling, etc.
Tobias: we've done some implementations and benchmarks. we'll make that
known.
Paul: There are differences betwen this and CRL. CRLs use old encoding.
the metadata is extremely verbose which makes it big. second CRL
contains ???? breaking up.
Aaron: if the list is all ones, can a bit only ever flip up, not down?
is that the intent?
Tobias: haven't decided yet.
Aaron: there are concerns if things can change back and forth. setting
aside VC stuff. would this work with the JWT access token spec?
Tobias: yes
Aaron: What are the advantages of using this?
Tobias: There are trade-offs. There are ways to check if a token is
valid. This would be another option where the scalability or privacy
options would be favorable.
RichARD: wanted to respond to Leif's reinvention point. that's what we
do here. more modern encodings. we should lean into that. don't think we
need to do the fancy math. gzip is fine. Expired credentials and how to
hanlde those might be interesting to explore. should be explicit about
that.
Dave: I normally don't care about privacy. Herd is interesting, but you
know who is getting the data. Trying to protect against evil issuer, can
be a bitmap of one. Seems to be up to the AS to decide how honorable to
be.
Tobias: this does rely on issuers acting on a large herd. There are
considerations
Phillip: I've done some compression schemes, The difference is closed vs
open set. There are a bunch of compression apporaches open to you with a
closed set. there are also range mechanisms and a serial number. Finally
- using bloom filters is based off my stuff, how to identity bad ones.
probabalistically used in first step then can do more. No, one of the
firmest conclusions was that it was a terrible idea to ???
Tobias: do you mean for specific statuses like revoked, or other
statuses like suspended. Suspension is by definition a temporary state.
Phillip: Using suspension turned into a nightmare
Mike: I wrote the status list at W3C that this is based on. Key lessons.
When we're looking at this where is can be distributed of=ver CDN. There
is an issue over how many times it can be signed. there should be a TTL
property so the validity can time out. Also the difference between
status and verificatuon. they may be different. Using credentials that
represent digital twins. regulatory items have to represent the status
that is pre-determined. Informational statuses may be externally defined
that say what the status codes mean. caution against locking down what
statuses mean so we can differenctiate betwen external statuses and
validation concerns.
Brent: The approach you are taking here is very similar to VC
Common cor being bit-map discription. Then take in GZip for JWT/CWT - I
think there is value in that. If we could explore that possibility
Tobias: That partin the specification is not that significant but
abastractign it out could be of less value to both specifications in
time.
Rifaat: We want to wrap this up. There is support for this document but
there is concerns. Do we need to wait before adoption. Thoughts?
Justin: My main concern is the scope and charter of OAuth. This feels
outside of OAuth.
Orie: you con't want them too
Justin: doesn't feel like it fits here. this is an important reinvention
of a wheel. (that's how we get rorund ones)
Roman at AD: Would like to talk about non-round wheels at some point.
From my perspective there is a lot of excitement around VCs. I don't
have my head wrapped around it.We may need to refactor the charter here
to coduify the trajectory of the work, or do we use liasions? OAuth is
long-standing with a vague charter.
Rifaat: we've been talking about VC coming here as a step toward
creating a VC working group.
Roman: we have no other place ti start the conversation, but there may
be momentum to end it somewhere else or to refactor this group.
Leif: re-iterate my support. Fact is OIDC is going to have a significant
role to play in EU wallet ecosystem. let's start the work somewhere.
Oauth is as good a place as any. This is possibly the last remainign
point that needs to be described.
Roman: we can continue to talk, but shouldn't call for adotpion, from my
perspective.
Rifaat - we can talk about all of these things at the same time
Kristina: when we say get started, we mean adopt the draft. there are a
lot of implementations that wnat to rely on the draft that need
something more stable. There is work all over that really needs this.
Justin's point acknowledged. Can we revisit the chart of OAuth? waiting
for formation of another working group is not an option for a lot of us
who want to rely on the work.
Rifaat: we can recharter. creating a new group can happen more quickly.
cant make decision now.
MikeP: I do support this. One of the challenges in using this in a
standardized way, particularly working this in W3C and IETF. This may be
better in COSE for example. Because that work it logically this one with
different names. the w3c work is essentially complete and will be a
standard soon. We want to make sure this is a significant imporvement.
There are other approaches that need IETF to handle.
Torsten: I'm a sd-jwt contributor and status list. very excited about
this to help with EUDI work. This is a very important component. this
work is being done in the same group sd-jwt, client-attenstation, and
this are ll here. eventually a new WG is better place, but by end of
year the underpinnings of eIDAS must be defined. StatusList is out of
scope of OAuth, but this is where the people are.
Paul: bad connection
Richard: Velocity enthusiast. We need to move quickly with this. Mimi
will need an identity layer. we need to be clean process-wise. a new
working group would be cleanest, but we have demonstrable engamenet
here. can we re-charter while discussing a new WG?
John: I agree with Richard. strike the iron whule it's hot. I don't
think we need to recharter to do a status list for JWTs. even if it can
be used for other things. We have justification to adopt these things.
Perhaps things can be spun out to toehr group later, but let's start on
work now.
Rifaat: I'll talk with chairs and ADs, then take things to the list. no
call for adoption now.
Henk: I want to say we have a hands tool and we should use it.
Rifaat: just to get a feeling, not official?
Henk: I would like you to feel that, please use the tool
ROMAN: we need to include remote folks. we are going to do a process
inject before moving forward.
Call for comments from remote folks. no one queues.
https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/
Brent's fingers are tired
Tobias presenting.
Motivation: on slide. narrowly focused use case, but more generally
useful. traditional public clients have no direct way to authenticate.
Proposed solution: on slide. JWT assertion framework extension. webapps
are often many instances of the same client. they share same client id,
there would be a backend service for sharing platform attestations.
signed with a key that is trusted for that client. 2 and 4 are out of
scope. want to define what this look like and how to put it in a
request. backend instance communication being undefiend.
Key callouts: This is proof of possession-based. concrete implementation
shown later. dPOP doesn't hanlde how you authenticate the dPOP key. the
Auth server has to trust that the key is good because it's there. this
can go on top of that to prove possession of the dPOP key.
Native app example: on slide. instance can talk to TPm on device for
generation of key. request for validation of attestation. mobile app now
in possession of attenstation for use wherever needed.
Example - token request - on slide. highlights differences. JWTs devided
by ~, similar to sd-jwt
Example client assertion: on slide (signatures are examples and not
valid)
example client attestation - on slide: URL could be used as client ID.
client attestation says it requres validation to be used.
Orie: on the cnf piece. can you refer tot he key or only use it
directly
Tobias: that is possible in 7800.
George: we often looked at a nonce in the flow so it can prove the
attestation relates to the verifier. Is there a reason you arenlt
looking at that.
Tobias: this is a proof from the issuer to the holder that is intended
to be passed on
George: the the client attestation could happen earlier. we don't have
way to do client authentication at the beginning. attestation of client
at authorization sevrer level provides knobs for users. I want to show
trhese things are all connected.
Tobias: talking pre-authorization request, can be issued there.
George: this happens outside of authorization flow and they should be
bound together
Aaron: glad to see proposal. one nit - technically if this is a form of
authentication of a private client, this isn't a private client anymore.
The attestation is a hint but not an absolute. the signal is useful in
many IETF flows. token endpoints where token are issued from, PAR
enpoint, Resource server. In OAuth world we would want to layer it on
those parts. We've done some deployements to accept iOS toekns and that
has been very useful. We have dPOP that can be used anywhere. we should
be able to use this the same way, like an HTTP header.
John: in the various POP things we've done, this was always the missing
piece. missing the OS APIs to make it happen. We should take this on..
More comments than I have time for. This is needed in a number of
different places.
Torsten: Reflecting on comments: yes we are looking for way to get nonce
included in flow. I don't think it is good to provide nonce in
attestation itself. This is intended to be long-lived. We started client
authentication work in eIDAS with authentication on top, that's why we
started that work there.
Peter: very supportive. good to generalize. I see use for this.
Justib: plus one to all generalization comments - where do attestations
fit has been discussed a lot this week. This would be a very good thing
to have. Putting in the nonce question - should absolutely be separate
from attestation itself. Great stab at it, need to pull concept back
because it will tocuh a lot of places.
Tobias: no more time for slides?
Rifaat: lots of support, we will call for adoption over the mailing
list.