Vladimir,
yes, we could do a formal analysis and it would be a very good idea.
It would even go faster if a few of us work together on it. Anyone
interested?
This would be a good contribution for the workshop in July, btw.
Ciao
Hannes
On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
> Hi Mike,
On 25/02/16 09:02, Manger, James wrote:
>> I'm concerned that forcing the AS to know about all RS's endpoints that will
>> accept it's tokens creates a very brittle deployment architecture
> The AS is issuing temporary credentials (access_tokens) to clients but
> doesn’t know where those creden
> I'm concerned that forcing the AS to know about all RS's endpoints that will
> accept it's tokens creates a very brittle deployment architecture
The AS is issuing temporary credentials (access_tokens) to clients but doesn’t
know where those credentials will work? That’s broken.
An AS should a
The link relations registry is a regular IANA registry, just like OAuth
parameters registry.
It is also available in XML format but so is the OAuth parameters
registry, i.e.:
http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml
You do not say that OAuth is XML based because th
And so does oracle and so does google. Each different.
So how can an app dictate it then unless we all go to a common architecture?
Phil
> On Feb 24, 2016, at 16:04, Mike Jones wrote:
>
> Azure defines ways for resource servers to be registered for use with a
> client and for clients to dyna
Azure defines ways for resource servers to be registered for use with a client
and for clients to dynamically request an access token for use at a particular
resource server. You can call that custom architecture if you want. It’s
well-defined but it’s not currently in the standards realm. I
Mike
Take a look at the assumptions you are making.
You seem to be assuming application software dictates oauth infrastructure
architecture by suggesting that apps register in iana.
Would ms azure allow custom arch?
Phil
> On Feb 24, 2016, at 15:28, Mike Jones wrote:
>
> The UserInfo End
The UserInfo Endpoint path isn’t fixed and so has to be discovered.
I agree that for some OAuth profiles, one or more resource servers will have to
be discovered starting from the authorization server. Working group members
have also described wanting to discover authorization servers starting
In section 3.2 under calculating header list hash, there's an example of
hashed headers. For the values:
content-type: application/json
etag: 742-3u8f34-3r2nvv3
this is shown as the example:
"h": [["content-type", "etag"],
"bZA981YJBrPlIzOvplbu3e7ueREXXr38vSkxIBYOaxI"]
I believe th
Yup. And because there many relations the client mist be able to discover it.
The client does not know if the res server is legit.
The userinfo is always fix and so u dont need discovery.
Phil
> On Feb 24, 2016, at 14:05, Mike Jones wrote:
>
> In OpenID Connect, there’s a resource server ca
In OpenID Connect, there’s a resource server called the UserInfo Endpoint that
returns claims about the authenticated user as a JSON data structure. Its
location is published in OpenID Connect discovery metadata as the
“userinfo_endpoint” metadata value, which is defined at
http://openid.net/s
Where is the profile endpoint (oidc's resource server) published? (For the non
OIDC people on the list).
Phil
> On Feb 24, 2016, at 13:09, Mike Jones wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same
> information as OpenID Connect – which is built on generic
To the extent that generic OAuth 2.0 needs to publish some of the same
information as OpenID Connect – which is built on generic OAuth 2.0 – it makes
sense to publish that information using exactly the same syntax, since that
syntax is already in widespread use. That what this draft accomplishe
So as I understand it in the Link Relations repository are XML documents that
one has to create, are you suggesting as part of this effort is to rewrite all
that in JSON and make a proposal for that also ?
From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Tuesday, February 16, 2016 4:55 PM
To
Mike
Publishing on dev pages does not work for software (esp open source) that is
deployed both in enterprises and on PaaS cloud providers.
The current draft is may codify current OIDC practice and be appropriate for
oidc but it is not ready for generic oauth. There is no generic oauth
experi
I think that AT reuse by MITM attacks should be dealt with as a separate issue.
There are several possibilities.
1) POP tokens (You will recall the Eran wanted them for this reason)
2) The AS telling the client where the token can be used and the client
comparing the URI (may be multiple)
3) The
I'm concerned that forcing the AS to know about all RS's endpoints that
will accept it's tokens creates a very brittle deployment architecture.
What if a RS moves to a new endpoint? All clients would be required to
get new tokens (if I understand correctly). And the RS move would have
to coordi
We could add a statement something like this to the security considerations:
“Publishing information about the authorization server in a standard format
makes it easier for both legitimate clients and attackers to use the
authorization server.”
I believe that speaks to the point you’re making.
Sure there is, it is as you have now made it far easier and the security
considerations does not even address this
From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin
Cc:
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
As we’d discussed in person, there’s no
As we’d discussed in person, there’s no effective security difference between
discovery information being published in an ad-hoc fashion on developer pages
and it being published in a standard format. “Security by obscurity” adds no
real security at all.
> The point of the WGLC is to finish standardizing the core discovery
> functionality that’s already widely deployed.
That may be widely deployed for OIDC but not widely deployed for OAuth. There
are some authentication mechanism discovery for endpoint that really should not
be in an OAuth stand
The point of the WGLC is to finish standardizing the core discovery
functionality that’s already widely deployed.
None of Nat or John or I are suggesting that additional related functionality
won’t be created. I’m sure it will be. Some applications will use WebFinger
to locate the discovery m
We still have a problem with AT leaking. I think that needs to be dealt with
separately.
Access tokens should have a audience (by value or by introspection) the client
needs to tell the AS what resource it want s to use the token at and have that
included as the audience or the request reject
I am suggesting that part of the discovery solution has to be the client
indicating what resource endpoint it wants the oauth configuration data for.
So if res.example.evil.com is not a valid resource endpoint for as.example.com
the authz discovery should fail in some way (eg return nothing).
Hi Phil,
Are you suggesting that the AS metadata should include the RS URIs?
Currently, it does not, but it can be done, I guess.
The way oauth-meta works is that
1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.
Even if there is a bad AS w
Right. As there can be multiple WWW-authenticate header, it is doable that
way. Maybe that's better in this respect, though it becomes a bit different
than other metadata. Alternatively, the scope can be added as a parameter
in the auri Web Link header.
Good things about the Link Header is that yo
Hi Nat,
On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura wrote:
>
> 2016年2月22日(月) 18:44 Thomas Broyer :
>
>
>> (well, except if there are several ASs each with different scopes; sounds
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with such a parameter such that an R
Nat,
I’m not sure that having the resource server tell the client where its
authorization server is secure by itself. The relationship between the
Authorization Server and the Resource server need to be bound together in one
of the discovery endpoints (the resource and/or the oauth service disc
Comments inline.
On 24/02/16 12:27, Nat Sakimura wrote:
> 2016年2月24日(水) 8:17 John Bradley :
> [..snip..]
>
>> This is not stoping the attack it is protecting code.
>>
> IMHO, this is the right approach. We should solve the problem
> architecturally rather than bandaging the hols.
>
>
>> I should p
Hi Thomas,
inline:
2016年2月22日(月) 18:44 Thomas Broyer :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to
> do discovery, and leave it open to implementers / to other specs to define
> a .well-known URL for "auto-configu
Hi All
I inadvertently started a private thread when replying to Vladimir, I
spotted it only now. Forwarding it back to the list.
Vladimir - many thanks
Sergey
Forwarded Message
Subject: Re: [OAUTH-WG] JWS Access Token concerns
Date: Wed, 24 Feb 2016 13:34:47 +0200
From: Vla
2016年2月24日(水) 8:17 John Bradley :
[..snip..]
>
> This is not stoping the attack it is protecting code.
>
IMHO, this is the right approach. We should solve the problem
architecturally rather than bandaging the hols.
>
> I should point out that some of the attacks like man in the middling
> regis
32 matches
Mail list logo
