Please respond to this Doodle Poll http://doodle.com/fvrkmr8qtiktc3um to
indicate which times you'd prefer to meet tomorrow (Tuesday) afternoon.
-- Mike
From: Mike Jones
Sent: Monday, March 11, 2013 3:38 PM
To: oauth@ietf.org
Subject: O
Similar work is in progress at Webfinger.
See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html
Paul is proposing the same syntax as Connect.
2013/3/12 Richer, Justin P.
> It does presume a definition of "claim", which I suppose we could turn to
> "metadata field" for DynR
It does presume a definition of "claim", which I suppose we could turn to
"metadata field" for DynReg and its extensions to be appropriately limiting.
But we also need a good definition of what a language-tag-less field means, and
whether or not it's required if the other fields are present or n
The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG
meeting today is attached and available at
http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx. Tony Nadalin and I
created it as a tool to characterize OAuth implementations to help promote
interoperability by unde
A fair question but what would need to be pulled in is really probably only
a couple sentences (and reference) from
http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts(note
the reference to 2.1.1.1.3 inside
http://openid.net/specs/openid-connect-registration-1_0-15
My concern with this is that OIDC can get away with defining this
multi-language structure because it defines the mechanism once (in Messages)
and applies it to all user-readable strings throughout the whole application
protocol, of which there are several. Do we really want to pull in that whol
That is what I was thinking. It would be up to the AS to determine what
language and script to present based on the user preference.
While a large number of clients will be native and might be able to customize
themselves for a single user during registration , we don't want to forget the
web
+1
2013/3/12 Brian Campbell
> FWIW, the closely related OpenID Connect client registration draft does
> have some support for doing this, which could maybe be borrowed. See
> client_name in §2 at
> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand
> the examples
FWIW, the closely related OpenID Connect client registration draft does
have some support for doing this, which could maybe be borrowed. See
client_name in §2 at
http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand
the examples.
"client_name": "My Example",
"cl
It was brought up at the in-person meeting today that we'll want to consider
issues around internationalization and localization of human-readable fields
like client_name in the client registration. Which is to say: if a client
supports ten languages and wants to present itself in ten languages,
Just a (perennial) reminder from me that scopes are proprietary strings in core
OAuth, but the UMA folks have proposed a way to standardize them because we
needed to:
http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
(pretty-printed, slightly updated version here:
http://docs.kant
+1. I think that is correct characterization.
Phil
Sent from my phone.
On 2013-03-11, at 12:42, Nat Sakimura wrote:
> No. I am not confusing scope with audience.
>
> There is no standard scope. So, the scope has to be either defined by the
> resource or the authorization server.
> Just st
No. I am not confusing scope with audience.
There is no standard scope. So, the scope has to be either defined by the
resource or the authorization server.
Just stating scope is too vague that you will not able to find out whose
scope it is.
That is why I wrote that the scope has to be understood
I would not even want to confuse audience with scope. Maybe in the simplest of
cases, where there is a one-to-one mapping between scope and audience, but in
reality the RS could expose multiple APIs at the same endpoint. Granted the RS
could extract the audience field based on a fully qualifie
FYI: in case you are interested in that conversation. The topic about the value
of TLS and the problems with the PKI have surfaced in the past on this list.
Begin forwarded message:
> From: Hannes Tschofenig
> Date: March 5, 2013 9:19:51 AM EST
> To: 86attend...@ietf.org
> Cc: Hannes Tschofeni
One thing that concerns me is that scope is very different from a claim. An
claim is an assertion provided that may have some level of dispute/quality etc.
A scope defines what is request or what has been authorized. It's an absolute
thing. Therefore it is not a claim. Audience...maybe.
This
16 matches
Mail list logo
