[Openid-specs-ab] Static webfinger for a domain

Justin P Richer jricher at mit.edu
Fri Sep 26 20:20:37 UTC 2014


For our case, the subject doesn't matter as much since the answer's always going to be the same no matter who they're asking about. This does lead to the interesting problem of people being able to ask for subjects that we have no control over, but then in those cases they shouldn't be asking us in the first place.

 -- Justin

________________________________________
From: Openid-specs-ab [openid-specs-ab-bounces at lists.openid.net] on behalf of Hans Zandbelt [hzandbelt at pingidentity.com]
Sent: Friday, September 26, 2014 1:20 PM
To: John Bradley
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Static webfinger for a domain

For in-browser clients using the Referer header may stand a chance but
not for mobile and web clients.

Hans.

On 9/26/14, 7:13 PM, John Bradley wrote:
> While not being a recommendation, if you redirect and can't get rewrite rules to include the subject in the redirect URI, you might be able to grab the subject from the referrer header.
>
>   Failing that don't include a subject in the response.
>
> John B.
>
> On Sep 26, 2014, at 10:55 AM, Hans Zandbelt <hzandbelt at pingidentity.com> wrote:
>
>> The WebFinger RFC7033 says in 4.2:
>>
>> "A WebFinger resource MAY redirect the client; if it does, the
>> redirection MUST only be to an "https" URI and the client MUST
>> perform certificate validation again when redirected."
>>
>> Whilst technically it does not say that a client MUST follow redirects, but at least the client must expect them and deal with it in some way.
>>
>> As far as "subject" in the response is concerned: an OpenID Connect client doing discovery would look for the "issuer" and may not even look for the "subject" (I know mod_auth_openidc doesn't...); even if it would, since it is optional it would have to deal with its absence properly.
>>
>> Not saying that all clients will behave like this, but it could be argued that if they don't they should be fixed.
>>
>> Hans.
>>
>> On 9/25/14, 4:28 PM, openid-specs-ab-request at lists.openid.net wrote:
>>> I'm very interested in this as well as I won't be able to deploy a
>>> dynamic endpoint on our domain either. My plan was to use the redirect
>>> mechanism to point the queries to an endpoint I do control. However, if
>>> clients don't implement that feature it's not going to work.
>>>
>>> Thanks,
>>> George
>>>
>>> On 9/25/14, 9:42 AM, Richer, Justin P. wrote:
>>>> We're looking to set up a static webfinger responder for an entire domain, and I'm not quite sure what to do. This file absolutely must be static, as no dynamic processing or server side code is allowed in this environment (at least, not without a writ of pardon from the president, so let's call it impossible). It's simplest for us to just return a file with an HTTP 200, and we should be able to set the media type. Since all accounts on the domain are pointed to the same server, we can return the same "rel" link every time. This is great, but it makes me scratch my head about what to do with the "subject" field in the response. It's only a "SHOULD" in the webfinger RFC, so we could leave it out. But are webfinger clients (particularly OIDC clients that do discovery) expecting it? If we do leave it in, what value should it take? It can't reflect the value of the "resource" parameter, since we can't have anything on the server to process the query parameters for this. We c
 ou
>> l
>>>   d
>>>>    put in the base URL of the domain, or some kind of wildcard perhaps. What is the best practice? I can't really see anything of note in the RFC or the OIDC Discovery docs for this case.
>>>>
>>>> Alternatively, Webfinger says we can return a redirect, "like a 307" but doesn't specify much beyond that. It might be possible for us to have a rewrite rule that captures the query parameters, but this is likely to be trickier to implement. Additionally, are webfinger clients able to follow these redirects properly? I just checked our own codebase, and I know that we don't. (But at least we have a TODO in there for it! Someday!)
>>>>
>>>> What is the best practice here, and what are other people doing? We can't be the only ones with such a top-level domain constraint.
>>>>
>>>>    -- Justin
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>
>>
>> --
>> Hans Zandbelt              | Sr. Technical Architect
>> hzandbelt at pingidentity.com | Ping Identity
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

--
Hans Zandbelt              | Sr. Technical Architect
hzandbelt at pingidentity.com | Ping Identity
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab


More information about the Openid-specs-ab mailing list