What I don't understand is that the existing structure also allows for
exactly that same use case. The difference is where the information is
carried. But since we're not locking down where or how that information
is specified, your application use case can do it how it makes sense.
I fully agree that these things should be defined separately, which is
why I want to keep it out of Dyn Reg all together. BB+ is its own
application and use case. My use case there is built on top of the
existing OAuth use cases. Yours is as well. I think there's absolutely
value in defining interoperability both at the common-denominator level
(DynReg) and the higher application level (the "other extension spec"
that I suggested this be turned in to at the very beginning of this
conversation). Would it be good if our two use cases could talk to each
other? Probably. But I think it's even *more* important that our two use
cases can be built on top of the same foundation.
So I am saying: let's finish the foundation with a clear set of
semantics that are useful on their own. The utility of the base DynReg
spec is well established today. I think there would be value in a
separate concrete extension that says things like how to pass signed
assertions around -- exactly like we did with OAuth. Its absence from
the core of OAuth has in no way diminished OAuth's popularity and
usefulness, and I would argue that the flexibility in the right places
has actually done much to encourage OAuth's adoption.
-- Justin
On 05/30/2013 01:00 PM, Phil Hunt wrote:
Justin,
You are right, 6750 does not define "local" or "3rd party". But the use cases
we are talking about are clearly very very different.
You are blurring the distinction between access tokens and bearer assertions
such as defined by draft-ietf-oauth-saml2-bearer and
draft-ietf-oauth-jwt-bearer.
In the BB+ case, the assertion you are passing fits none of the 3 above. It
isn't a local access token (of some unspecified format), and it isn't a JWT or
SAML Bearer assertion.
Saying the AS is free to do whatever it wants undermines the value of having a
standard.
I propose to keep these concepts separated and clearly defined.
The proposal I have outlined below allows for a piece of software (with a
signed set of metadata) to be approved by an admin and a locally issued access
token to be issued so that separate client instances can be registered with the
locally issued access token.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-30, at 9:42 AM, Justin Richer wrote:
But OAuth says nothing about whether tokens are "local" or "3rd party", and
this spec inherits that definition. The AS is free to do whatever it wants with the token. You can
already do both scenarios that you're talking about below with the existing functionality (in a way
that makes sense), so I just don't see the value in adding another parameter to handle that case.
Yes, some registration endpoint implementations won't be able to handle
external assertions as their OAuth tokens and won't have access to them at the
right levels. But, that's already true for other kinds of protected resource,
isn't it? As far as DynReg is concerned, I want it to just stay an OAuth
protected resource. What you do with it beyond that (like what we're doing in
BB+) is of no concern to the base spec.
As I've said before, I'm not opposed to adding a very strictly defined,
optional software_id field (if others agree), but I'm not OK with defining
assertion semantics there. I'm also not OK with defining assertion semantics in
the Initial Registration Token. Both of these are too implementation specific,
and from the client/developer's perspective these tokens ought to remain
opaque, like OAuth tokens always are.
-- Justin
On 05/30/2013 12:36 PM, Phil Hunt wrote:
In 1.4.1 - I'm ok with this use of having the AS token endpoint issue an access
token to an anonymous client to begin the registration process (just not sure
the value of it).
I'm not ok with what is happening in 1.4.2 (Protected Registration).
I think we should make it clear that it is for Protected *Local* Registration.
In this case it makes sense that the local OOB registration process could
reasonably issue a local access token.
A new option (1.4.3), Protected 3rd Party Registration would proceed
differently (the BB+ case)….
It opens the door for a scenarios such as where a certifying entity, e.g. the
publisher of a REST API issues the developer a client application assertion
that includes some defined application metadata. We should specify what claims
are typically present and what is minimally required.
Because this assertion is not an AuthN statement (technically), my preference
is that this assertion then be presented as the software_id because it is
identifying the software and represents assertions about client metadata.
IMPORTANT: By NOT presenting the 3rd party assertion as the initial access token,
it is possible for an administrator to then take that assertion and locally
register the application --> converting the client application registration to
a 1.4.2 local registration. The client would still present the 3rd party
assertion as the software_id AND the initial access token from the manual
registration.
OR,
The client registers *anonymously* but presents the signed 3rd party assertion
in software_id.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-30, at 9:08 AM, John Bradley wrote:
The initial access token is a OAuth bearer Access token (Authz). Like any
bearer token it can be structured or not. Your concern is I think around some
work BB+ has done to profile a structured token for this particular RS use.
That is out of scope for the core of dynamic registration, as it is out of
scope for OAuth core.
So http basic vs parameters makes no difference to you. The assertion profile
only uses POST parameters for the assertion rather than headers so that should
not be an issue for that authentication method.
John B.
On 2013-05-30, at 11:52 AM, Phil Hunt <phil.h...@oracle.com> wrote:
No different issue. I was concerned about the initial client assertion being
passed in as authen cred. It is a signed set of client reg metadata.
See we are confused. Hence my worry. :-)
Phil
On 2013-05-30, at 8:48, John Bradley <ve7...@ve7jtb.com> wrote:
I think Phil also had some processing reason why a Token endpoint or RS
wouldn't want to tale the authentication as a header, as the processing was
easier with them as parameters as they are potentially available to different
parts of the stack. That may have been mostly around RS, but the principal
may apply to the token endpoint as well.
On 2013-05-30, at 10:21 AM, Justin Richer <jric...@mitre.org> wrote:
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client
secret. If an authorization server supports both, both should work for any
client. So are both methods treated differently?
I agree, and this was one of my original arguments for making this field plural
(or plural-able), but there hasn't been WG support for that so far.
I'm not arguing to make it plural. I think the authentication method is just
"client_secret".
That was also an option that was brought up, but in the OIDC WG the
counter-argument was (as I recall) that the two are syntactically separate and
there's a desire to restrict to a single type, such as disabling
client_secret_post. Basically, to make it unambiguous.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
