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
[email protected]
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
